r00ty

A relay is like an instance in AP. It hosts content and relays content from other relays according to its own moderation policies. The difference in nostr is that most users are usually connected to multiple relays, whereas an AP a user is connected to one ‘instance’ and their instance connects to other instances.

Thanks, I think I’ll have to read up on the details later though to get a clear idea of what is stored where, where accounts are created and held and so on.

But then what is a relay? See if a relay doesn’t hold an account and cannot ban/moderate directly content they serve then what’s exactly happening?

I also wonder if it’s a bit of a legal minefield. See I’m running mbin here. I get content from many other mbin/kbin/lemmy instances. Usually they have pretty good moderation and content is removed on my instance too. But, if someone raises a legal complaint with me directly, I’m required to act on that and moderate on my own instance. Which I can do. It seems like you’re suggesting that’s not directly possible with nostr? So if the main instance chooses to allow it, then it’s tough luck for me, I am required to host it?

Here’s why I think activitypub is probably better.

Having multiple instances, hundreds or even thousands, spreads the load of the network. Smaller instances can curate the communities they want to subscribe to in order to limit traffic and storage. Communities can be hosted across the network too to reduce load on single instances.

This means that when things are done well, we could produce and serve reddit/twitter levels of content and availability on hobbyist level hosting options spread across the world.

And a pizza party at the end of the year!

Note: Pizza will count as a taxable benefit in kind.

The constant growth aspect of capitalism means that profits are never obscene enough for any business.

Yep. The ISP doesn’t offer it any more. They stopped, I think when RIPE officially “ran out” of new net blocks. But I’ve moved address twice so far and have kept the allocation. Well, on the last move they messed up and gave new a new single IP. I complained, and they asked why it matters so much to have my old IP. I pointed out I had a netblock, and they fixed it up pretty quickly.

Pretty soon, full fibre will be in my area and available on the same ISP. So, hoping for a smooth transition to keep it for a bit longer.

And this is why I’m unlikely to change isp. I have a /29 ipv4 block and /48 ipv6 block. No extra charge. Grandfathered features from over a decade ago.

But pii isn’t being sent. A user’s nickname and the domain of their instance plus any content they create is. If they choose to put their pii in public posts or user info, that’s their choice but is not pii solicited in order to operate the service, it was volunteered.

It’s a crucial difference. I considered this when writing the terms and data retention information for my own instance. Federation is very frugal about the information shared.

No. I think we mostly want federating instances to respect delete requests. But only the instance actually contacted has any onus to delete on their own instance and maybe, maybe try to send requests to delete elsewhere.

There’s no way there’s an expectation that the originating instance has a legal requirement to remove it from anywhere else.

It’s not really as simple as that. Businesses in countries outside the EU have to follow the gdpr rules if they have or want customers from the EU because the EU can hit them financially in their EU operations.

Normal people offering a free service that are not based in the EU probably cannot be pursued at all. I doubt the EU considered people that might not be some business wanting to profit from EU citizens.

I think in terms of gdpr, if you notify a site that is providing service (allows users to register from I guess) to EU countries you want something deleted, they need to comply.

But I think in terms of federated content, you cannot be expected to do more than send information about the deletion out. If other instances don’t respect it, it’s not the originating instance’s job to police it.

Now the user could go to these other instances and chase it up. But I wonder if a third party instance doesn’t allow users from EU countries, if they’d be required to comply? Federated content opens up a an interesting set of scenarios that will surely test privacy laws.

I also wonder what the EU powers are to sites in non EU countries that allow EU users but don’t respect GDPR. what can they even do? Companies like twitter, Facebook, reddit etc have presences in EU countries that can be pursued, but John Smith running a lemmy instance on a $5 vps might be out of reach.

That was also the case on reddit though. It’s just the demographic making up the norm were somewhat different. So, different subjects will get that response.

My solution is posting from my own kbin instance. I only see the upvotes here :P

Where are you getting email and ip from?

What info do you think they will get? The only info is what you put in the public info on the user profile on your instance. So they can get your username (well user@instance), avatar, about info. That’s about it. Anything else like email address and password hashes are only stored on the instance you signed up to.

Well, the answer is “it depends”

For the community as a whole, I would say that the instance that hosts the community must be up to federate any new posts to other instances. Because it works a bit like:

Instance A hosts Community 01.
Instance B user posts to Community 01.
Instance B federates the post to Instance A
Instance A federates the post to Instances C, and D.

So, if instance A is down, the post will exist only on instance B.

But, federating the posts and comments themselves is not the only way an instance will get posts and comments. Consider the following situation. The post above exists on instances A-D. But after it is posted, Instance E subscribes to the community. Instance E will not have the above post. They will only start getting new federation events.

However, say for example someone on instance C likes the post? The like event will be sent to Instance E. Instance E will see the like, try to find the post (the post/comment URL is included in the like event) and fail. So, it will then look up the original post. Here’s where it gets interesting. That URL will not be on Instance A where the community lives, but on Instance B where it was posted. So, in this case, if Instance B is down, Instance E will not be able to fetch the post.

However, if all the instances are up, Instance E will get the post add the like and add to database. This is why when subscribing to instances you will get some old content appear but not all. Because if the old content is interacted with, it will be fetched to render the interactions.

This understanding is based on my understanding of kbin federation. But, I would be very surprised if lemmy did not work the same.

EDIT:

To be clear, to see what already is federated no other instances except the one you’re visiting need to be up. For federation of live events happening to a community, the instance hosting the community must be up and to fetch content needed for a federation event (for which the referenced object was not received via federation), the instance the content was created must be up.

Pretty good answer but there’s no periodic sync. From the moment a community is subscribed to, the instance that is home to the community will send all activities in that community to the subscribed instances as they happen.

That’s why you don’t see old content all being synced. Just new content (and some old content if it is liked or replied to after subscribed)

I think kbin is still quite new. It’s being updated daily and really your choices are larger instances that probably stage updates to make sure they don’t break everything and smaller instances that are more likely to be up to date with the latest version.

In my case I’m running an instance that is generally on the latest version but also with some of my latest submissions (pull requests) applied too.

It’s a double edged sword. I’m generally running with the latest changes. But sometimes the latest changes break things. I had around 30 minutes downtime today for example.

The fediverse isn’t established tech yet, lemmy and kbin are still effectively alpha versions. The whole thing is likely to be rough around the edges for a while. But it’s still usually working well I think.

I was suggesting (I actually clearly said it in both comments) hashing the post/comment ID + userid NOT the content. Just enough info to get a unique ID. We don’t need it not to be non-reversible. Just a unique ID for the like.

I think what changed early on was that there wasn’t upvotes, only boost. When upvotes were added they went in as favourites.

I changed some code relating to a race condition with multiple consumer processes when a comment is like/unlike cycled and the messages come in together. I couldn’t find any code for that. Also there is a PR for adding this suggesting it didn’t exist before too.

Also the fact I don’t see downvotes on my own instance is another sign.

Why would editing do that? I was talking about using the ids which wouldn’t change on an edit.

In any case, I don’t have a problem with this info being federated. Some people do, so it’s worth talking about ways it could be done.