5 ms·

This is exactly the reason why decentralised services cannot win. People talk about Mastodon instead of Twitter, or Lemmy instead of Reddit, but the overwhelmin

This is exactly the reason why decentralised services cannot win. People talk about Mastodon instead of Twitter, or Lemmy instead of Reddit, but the overwhelming majority of users wants convenience above everything else. They don't want to figure out which instance to join and how to get access to federated content.

didntcheck 3y ago
What's frustrating is that single sign-on and federated identity is a well, well solved problem, yet we barely use it. Outside of B2B setups, the best we get is "sign in with {Google,Facebook,Apple}". No thanks. And the even more frustrating part is knowing that those logins are implemented with OAuth or OpenID, yet arbitrarily limited to a few megacorps
- paulmd 3y ago
  yeah people arbitrarily throw content federation and identity federation into the same bin. you can get a lot of the squeeze of a centralized reddit-style service (in terms of low-friction user signup) without needing actual content federation. One ID can still let you post on multiple boards without needing to sign up in 27 places, and that doesn't need content federation. It also significantly reduces the moderation problem because now you are letting {Google,Facebook,Apple} solve (or at least gate/significantly reduce) the spammers problem for you. That said, custom IDPs are inherently at odds with this value in spam filtering. If a spammer just needs to set up a custom domain, you don't get any signal as to user quality.
  - didntcheck 3y ago
    Yeah this is how I feel about Lemmy. The only federation I care about is being able to use one account to post on many subreddit-equivalents, but beyond that the only link between communities on Reddit was plain old hyperlinks. No need for the backends to talk to each other at all. Assembling the feeds from all subs into a single timeline should be something the client does
- dcow 3y ago
  I also pine for a world where I can put in my own IDP url and login anywhere. But you have to admit that the UX of such a flow is hard to solve for the general user which is why we have crummy “log in with X” buttons.
  - detourdog 3y ago
    I got a standalone access controller for my building that uses LDAP for accounts. I have it pointed a 10.6.8 server that resolves to id.cogs.com on my internal network. Long ago I had an OD server acting as the backed for OpenID and all of that pointed to id.cogs.com. I'm trying to recreate that set-up again now. Considering how long Apple has been rolling out Apple ID and they are only now at the point where they may trust the users with their own key-server I think demonstrates that. When it works it's magic and when broken might as well give up. A backup can always save you depending on the timestamp.
- detourdog 3y ago
  I think Apple is about to open up Passkey management to device owner. This will essentially turn every Apple device kerberos type key manager. This will open up federation with a new level of authentication. The only hitch is that one has to trust Apple as the key manager. Everyone that can get past that hurdle will be able to manage very sophisticated trust relationships.
armitron 3y ago
Winning doesn't have to be a popularity contest. The majority can stick with Discord/gifs/microtransactions. As long as I can still have interesting discussions with super-smart folks on IRC, I'm happy (maybe even more happy than I used to be, there's enormous value in a high signal-to-noise ratio).
vvillena 3y ago
Convenience doesn't require centralization nor a walled-garden approach. It's just not a priority to the people developing the alternatives. Let's use Lemmy as an example. The current UI makes it clear at all times where the communities and the users are located. It's nice to provide such information, but in the end it should not matter, and thus it should not be wasting premium UI space. Same thing goes with the community list: the "subscribed" section works as expected, but "local" should never be the default view, because in the end, users shouldn't have to care where communities are hosted. Finally, the search feature should be much more explicit in describing the corpus of data being searched: "all known communities", "communities federated into this instance", "local communities". All new users think it's #1, but #1 doesn't exist, it's #2, and this leads these users to think they have to be on one of the big instances if they want to participate in a larger community. It's almost like federation was an afterthought.
- this_user 3y ago
  > Convenience doesn't require centralization Of course it does, because otherwise you are dealing with a patchwork of different entities operating parts of the federated system. Those entities are most likely operating with different standards and different levels of professionalism. In the end, you are offloading tasks to the end users like figuring out the structure of it all, where to sign up, which instances to join, how to get access to the content you are looking for, what to do when things inevitably break. In a centralised system, most of these questions don't exist, and everything else is being taken care of by the operator who has a vested interest in things running as smoothly as possible. What you are describing are mostly UI problems, but even if those had been solved, it would still a worse experience. The average user doesn't even know what "federated" means, the don't want to be thinking about local and remote instances, they just want things to work.
  - vvillena 3y ago
    > The average user [...] just want things to work. Indeed. This is why convenience means moving all things 'federation' to the background. Remember eDonkey, eMule, and the ED2K network? It started as a federated network, and it added a second decentralized network later on. And it was successful, because users didn't have to care about the inner workings of the product. There were a bunch of external sites acting as link aggregators, but there was a builtin search feature too that worked well (until hash collisions catched up with the stagnant protocol). To me, this is still a shining example of how to do federation right. There were multiple clients, standard communication protocols, and it was easy to take advantage of the full federated network, because it didn't take any effort to do so.
dumpsterlid 3y ago
[dead]
throw2022110401 3y ago
This gets parroted a lot but it's the wrong way to look at it. The Fediverse doesn't need to "win". It just needs to be good enough for those of us who use it.

didntcheck 3y ago

What's frustrating is that single sign-on and federated identity is a well, well solved problem, yet we barely use it. Outside of B2B setups, the best we get is "sign in with {Google,Facebook,Apple}". No thanks. And the even more frustrating part is knowing that those logins are implemented with OAuth or OpenID, yet arbitrarily limited to a few megacorps

paulmd 3y ago
yeah people arbitrarily throw content federation and identity federation into the same bin. you can get a lot of the squeeze of a centralized reddit-style service (in terms of low-friction user signup) without needing actual content federation. One ID can still let you post on multiple boards without needing to sign up in 27 places, and that doesn't need content federation. It also significantly reduces the moderation problem because now you are letting {Google,Facebook,Apple} solve (or at least gate/significantly reduce) the spammers problem for you. That said, custom IDPs are inherently at odds with this value in spam filtering. If a spammer just needs to set up a custom domain, you don't get any signal as to user quality.
- didntcheck 3y ago
  Yeah this is how I feel about Lemmy. The only federation I care about is being able to use one account to post on many subreddit-equivalents, but beyond that the only link between communities on Reddit was plain old hyperlinks. No need for the backends to talk to each other at all. Assembling the feeds from all subs into a single timeline should be something the client does
dcow 3y ago
I also pine for a world where I can put in my own IDP url and login anywhere. But you have to admit that the UX of such a flow is hard to solve for the general user which is why we have crummy “log in with X” buttons.
- detourdog 3y ago
  I got a standalone access controller for my building that uses LDAP for accounts. I have it pointed a 10.6.8 server that resolves to id.cogs.com on my internal network. Long ago I had an OD server acting as the backed for OpenID and all of that pointed to id.cogs.com. I'm trying to recreate that set-up again now. Considering how long Apple has been rolling out Apple ID and they are only now at the point where they may trust the users with their own key-server I think demonstrates that. When it works it's magic and when broken might as well give up. A backup can always save you depending on the timestamp.
detourdog 3y ago
I think Apple is about to open up Passkey management to device owner. This will essentially turn every Apple device kerberos type key manager. This will open up federation with a new level of authentication. The only hitch is that one has to trust Apple as the key manager. Everyone that can get past that hurdle will be able to manage very sophisticated trust relationships.

armitron 3y ago

Winning doesn't have to be a popularity contest. The majority can stick with Discord/gifs/microtransactions. As long as I can still have interesting discussions with super-smart folks on IRC, I'm happy (maybe even more happy than I used to be, there's enormous value in a high signal-to-noise ratio).

vvillena 3y ago

Convenience doesn't require centralization nor a walled-garden approach. It's just not a priority to the people developing the alternatives. Let's use Lemmy as an example. The current UI makes it clear at all times where the communities and the users are located. It's nice to provide such information, but in the end it should not matter, and thus it should not be wasting premium UI space. Same thing goes with the community list: the "subscribed" section works as expected, but "local" should never be the default view, because in the end, users shouldn't have to care where communities are hosted. Finally, the search feature should be much more explicit in describing the corpus of data being searched: "all known communities", "communities federated into this instance", "local communities". All new users think it's #1, but #1 doesn't exist, it's #2, and this leads these users to think they have to be on one of the big instances if they want to participate in a larger community. It's almost like federation was an afterthought.

this_user 3y ago
> Convenience doesn't require centralization Of course it does, because otherwise you are dealing with a patchwork of different entities operating parts of the federated system. Those entities are most likely operating with different standards and different levels of professionalism. In the end, you are offloading tasks to the end users like figuring out the structure of it all, where to sign up, which instances to join, how to get access to the content you are looking for, what to do when things inevitably break. In a centralised system, most of these questions don't exist, and everything else is being taken care of by the operator who has a vested interest in things running as smoothly as possible. What you are describing are mostly UI problems, but even if those had been solved, it would still a worse experience. The average user doesn't even know what "federated" means, the don't want to be thinking about local and remote instances, they just want things to work.
- vvillena 3y ago
  > The average user [...] just want things to work. Indeed. This is why convenience means moving all things 'federation' to the background. Remember eDonkey, eMule, and the ED2K network? It started as a federated network, and it added a second decentralized network later on. And it was successful, because users didn't have to care about the inner workings of the product. There were a bunch of external sites acting as link aggregators, but there was a builtin search feature too that worked well (until hash collisions catched up with the stagnant protocol). To me, this is still a shining example of how to do federation right. There were multiple clients, standard communication protocols, and it was easy to take advantage of the full federated network, because it didn't take any effort to do so.

dumpsterlid 3y ago

[dead]

throw2022110401 3y ago

This gets parroted a lot but it's the wrong way to look at it. The Fediverse doesn't need to "win". It just needs to be good enough for those of us who use it.