r00ty

Ah, so the kind of crypto bro, that instead of a fistbump, does a diffie-hellman key exchange instead?

I mean I could have used the GDPR (still a thing in the UK, at least for now). But didn’t see it as worth it. It really wouldn’t be worth the risk selling data that was deleted from a GDPR request.

I don’t know that they’ll risk using the data from deleted posts/comments though anyway. Most comments and posts will be deleted for a reason (moderation, or otherwise mistakes) and as such, likely isn’t going to make the best training data really.

It’s far easier to just sell the live data and be done with it.

I think there were historically interoperability issues, and there used to be (my version of mbin is quite old), and maybe still are issues federating dislikes (which stems from the way they were seen in kbin, which straddles both thread based and mastadonesque sides of the fediverse). But overall there’s aren’t the larger federation issues there used to be.

Right now, the choice mainly comes down to the interface you prefer, and if you perhaps want a limited ability to work with mastadon type posts. Since you can follow mastadon users and see their posts within the mbin interface.

I did think of a few ways round it (in kbin/mbin) a year or so ago. But, it wouldn’t work unless everyone using ActivityPub recognized it. It’s also really a small problem in reality. It’s likes and dislikes.

When I left reddit over the paid api, I left all my posts there.

But as soon as I heard about the plans re AI, I edited then deleted all content.

I see no reason why reddit should profit from my intellectual property without even consulting me about it.

The thing is, this actually if anything proves the strength of the fediverse. Lemmy.world is not Lemmy and Lemmy is not the fediverse. Just find another instance that has not blocked the community yet and carry on with your day.

Lemmy.world have every right to curate the experience for their users as they see fit and/or feel comfortable carrying the risk for.

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.

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.

On kbin/mbin you can look at https://<instance>/federation it has a list of known instances and right at the end is the list of defederated ones.

Pretty much wanted to say similar. Ip address isn’t known beyond your local instance (and any retention time and purposes should be stated in their privacy policy).

The rest is standard data any federation app will collect upon seeing content from a user.

It’s also worth noting that in general the user URL (which provides this user data) is generally also public. So if you know the user url you can get this too.

Having said that, I do wonder how much they can monetize third party data about people that have not agreed to their privacy policy that grants such uses. It’ll be interesting to see.

I think it only recognizes as “valid”, lemmy instances. But kbin will be searched and it at least listed those instances federated with me.

Yes, it’s by far a better situation that the rest of the threadiverse goes on. But, it’s definitely a large block of communities over there.

Well, a lot of the communities are hosted on world. I know they make the biggest single contribution to my federation ingress. So, I mean you will kinda notice a bit of a content drought if they’re down long enough.

Yep I read through it in the end. Looks like they were applying changes to all rows in a table instead of just one on a trigger. The first part of my comment was based on reading comments here. I’d not seen the link to the issue at that stage. Hence the edit I made.

Whose fault is it though? If an instance is capable of 100 concurrent users but everyone flocks to the two or three big instances. What to do? Block instances so they shutdown? Then when the shit really hits the fan there’s nowhere to distribute users to.

In the case of lemmy.world I might suggest they split the instance. Original lemmy.world keeps the communities but has no users. Create a new instance and transfer the users. That way the first instance is dedicated to federating the communities, moving the real time user database hits to a separate database. I’d also suggest preventing the creation of new communities on that instance.

In real terms it’d have been better if the communities were shared between instances more. Making a more even spread of the one to many distribution efforts.