I’ve been looking for a free Reddit alternative and preferably one that was federated. I’m not really sure how federation works with this though. A lot of similar sites are just personal projects that people made as a hobby that lack a lot of important features or the interface was really ugly.
I haven’t seen how to moderate communities though but the Github page says this can be done, which I consider important since I want moderation to be done by communities and users rather then admins. If there’s a quarantine feature similar to Reddit that would be useful too so I don’t just have to ban communities.
Of course, I agree that if we separate community instances from user instances, there is no need for community instances to federate with each other. They only need to federate with user instances.
In turn, user instances may or may not federate with each other. That’s the rest of the discussion. If they don’t, it means there is no user-to-user interaction independently from communities, right? For example no direct message feature.
So you claim there should be a separate service for each community-independent feature : one for providing ID, maybe one for DM, one for sharing blocklists, … That is indeed another way to do it, I don’t think I ever claimed federated user instances was the only one. It is still one way, and it has its own disadvantages but also advantages over the one you advocate for.
Maybe true if you want to check a specific content, what I mostly meant was that if you want to check an updated community feed, the community instance is aware you do that request. The user instance is an intermediate who doesn’t have to tell which user is checking the feed.
But even for the former use, it is not always true : what if you are using a webclient from a shared computer?
First, same argument as before : you need to tell every community instance in you subscription that you are checking your history.
Also, that means basically that you lose your own content when that instance shuts down.
For this latest two points, the idea is really that you can trust a single (ideally small scale) user-instance instead of vetting each community instance that hosts content that you are interested in. Can be useful if most communities are on an instance that one day turns evil :)
Not negating that.
Not having an account is still an advantage though, as google doesn’t know anything about what you exchange with people who don’t use it. Federation allows you to
get that level of “leaving the main instance”
keep in touch with people still on the main instance
keep in touch with people who completely left it, without exposing them to it.
Yes. That’s the gist of it. I feel we are reaching an understanding, I’m hoping our comments will start getting smaller :P (although I do enjoy the conversation).
Also note: imho, there’s a big difference between serving content through federation for 1-on-1 private communication that can be encrypted end-to-end where not even the server knows what data is being exchanged, and hosting public content for everyone to see. I suspect this is why XMPP / Matrix can more easily federate openly without leaning towards whitelisting. This is why I’m not so worried about 1-on-1 conversations. In fact, just use XMPP/Matrix (or even email!) for private communication, no need to reinvent the wheel. The user-instance could even just be an XMPP/Matrix server and make use of their pubsub layer for the notifications on new replies.
This is true, but there can be ways to mitigate that too. If the community is public, the API to retrieve the community feed doesn’t need to be authenticated, you might only need to authenticate the request if you want to submit content or if the community is private. And in both of those cases, even if there was an intermediary, I expect there should be a way for the original instance that hosts the community to make sure the user has the rights to do that operation on their instance, so they would have to know either way.
They still can know your IP, but that’s a different level and using the same IP doesn’t mean you are the same person. Specially when using shared computers or moving around. And you’d still have that issue if you host your own user instance to cache your accessed content.
Personally I don’t have a problem with the community-instance knowing I’m accessing the content, specially if that’s the cost of mitigating whitelisting. After all, the whole internet works this way already.
My motivation for federation is in the decentralized and open nature of it. I’m ok with having data (as well as knowledge of me accessing that data) across smaller servers, because as long as they are small and I don’t use them primarily, they won’t be able to know what I do outside of their domain, only what I do when accessing that server. The issue is when not only there’s one predominant server hosting most of the content, but also there’s whitelisting that makes federating with it and self-hosting troublesome.
That depends on what you compare it with. The 3 points you enumerate can be done without needing communities to federate among themselves.
Note that in this section of the conversation we are not comparing “closed walled gardens” vs “federation”. The point we were discussing in this branch of the conversation was: would it be bad if one instance (ie. lemmy.ml… or gmail.com for email) is central to a substantial majority of the activity?
When I said “embrace the centralization”, I didn’t mean making it a walled garden, I meant replacing the federation between communities with shared services. With user accounts being shared it wouldn’t be any more of a closed network than it already is (it might actually be less closed if it leads to removing whitelisting). I’d mean communities will be accepted as a centralized aspect that lives in one instance, even if other aspects (like user accounts) are decentralized. Essentially this would remove pressure from the community instance to have to serve third party content since that’s the requirement for federation. And with that pressure removed, I think there’s much less of a reason to do whitelisting (the only reason left would be avoiding toxic users, but that can be done in other ways as discussed, or at the very least the whitelisting could be limited to content submission rather than content access, so you don’t need to create different accounts for accessing different networks that don’t connect with each other).
The alternative to “embracing the centralization” is actually pushing for decentralization. Trying to fight the social snowball effect that might make big instances more attractive to use than small ones and implementing more cross-instance ways to access the content so that the system is more decentralized. Attempt to minimize the impact of a community “belonging” to one instance, so that smaller communities in smaller instances can compete for user attention in fairer conditions.
I also think we are coming close to the end of this nice but long conversation.
We both understand that what a user instance does can be done by several small services. The latter gives you more control, but the former gives you administrative simplicity. I guess which one is desirable is a matter of taste. It may be nice indeed if it was possible to do those things separately, but there would still be combined offers.
There’s also the question of whether the community instance need to serve the user instance (name we give to the above combination of services) or directly to the client. The advantage of the former is that the community instance doesn’t know anybody checked the content in question, as it was regularly served to the user instance (from what I understand fron activitypub, the content is sent to the instance with the indication of who can access it). As you point out, the request may not need authentification, which makes it less dramatic, but I’m sure data recombination can get creative.
Note that aside from the theoretical question of which is the best protocol, being able to talk to a user instance is necessary if Lemmy wants to connect with the rest of the fediverse someday.
A disadvantage of federation is that one may end up serving undesired content. You mention whitelist as a crucial point here, but again it only changes the speed of connection with unknown servers, thereby only helping when discovering evil instances. When a trusted instance turns evil, it really doesn’t change anything. So the usefulness of whitelisting depends on the rate of appearance of new evil instances. I don’t know how much it is in practice, but that most of the fediverse use blacklist might indicate it’s not that dramatic.
To be honest, I’m not a big fan of Twitter-like services (I find there’s way too much noise in such feeds), so I never really explored the Fediverse surrounding activitypub too much. Any criticism I have on Lemmy current structure is likely to extend to other parts of the Fediverse where similar approaches apply. So I guess you could see my points as rants on that approach for public cross-publishing in general, rather than Lemmy in particular. I guess I picked the target I feel the most interest towards and that I think has the most potential to become something I could use a lot.
If Mastodon (and the activitypub fediverse in general) has the same approach of cross-publishing and forces instances to serve the content from third parties, I think it’s risky that they don’t have a stronger policy towards whitelisting that imposes a tight control over what instances are allowed to have their content served through them, imho it’s asking for trouble to appear. So I think whitelisting was a justified approach in case of lemmy.
In my mind, the issue with whitelisting/blocklisting is the limitation on the reach of the federation. People would have to create multiple accounts to access networks that don’t federate, rather than using one account that can access it all. It makes sense for an internet forum to ban users, block them. But it would make no sense for an internet forum to explicitly block their (legit) users from visiting other forums.
So, ideally, it would be best to find a solution that allows users to access any instance that’s technically compliant with the protocol without having to impose the burden on each instance host to carry responsibility for the content of other instances.