5 ms·

Talking about IRC in particular, the reason I'm on Discord is: (a) UX far beyond anything I've seen with IRC (b) super easy for people to create new Discord "

Talking about IRC in particular, the reason I'm on Discord is: (a) UX far beyond anything I've seen with IRC (b) super easy for people to create new Discord "servers" (c) super easy to discover or link to Discord servers Talking about social microblogging/commenting (aka Twitter), the reasons I joined then later exited the ActivityPub "fediverse": (a) Twitter's discovery is massively better (b) My "identity" was not portable between instances (that's different from user on Network A interacting with user on Network B), also no easy way to link multiple instance identities If bluesky can solve all these identity/discovery/onboarding UX issues in the context of an open protocol, it'll be a massive step forward.

rglullis 5y ago
> My "identity" was not portable between instances (that's different from user on Network A interacting with user on Network B), also no easy way to link multiple instance identities That is by design. It's a federated system! Just like you don't need multiple phone numbers to talk with people in different networks, or different email addresses depending on the recipient, you don't need different identities to communicate with different servers. Unless you want to keep your identities separate, there is no point in having multiple accounts.
- d110af5ccf 5y ago
  > Unless you want to keep your identities separate, there is no point in having multiple accounts. Until an instance goes down either temporarily or permanently and it was your only account. Then you'll wish you'd had a few extras. How many email addresses do you have? From how many independent providers? Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. In fact they already don't, a single identity already commonly has multiple accounts. The software just isn't aware of this fact and has no standardized way to communicate it.
  - rglullis 5y ago
    > Until an instance goes down either temporarily or permanently and it was your only account. That's a technical problem, but not a UX or system design one. If a server goes down, my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one. > Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server". In any case, I totally understand the use case and I tried to get the Pleroma devs to focus on this idea as well: https://mastodon.communick.com/@raphael/106825107786781891 https://mastodon.communick.com/@raphael/106825107786781891
    - d110af5ccf 5y ago
      > my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one. The same issue exists for other services including email, irc, and matrix. The obvious simple and immediate solution is to retain copies of things you care about locally instead of expecting a particular service to stick around forever. With email this used to be standard practice before the rise of webmail. Even now most desktop clients sync to and retain a copy of everything on the local device. > > Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. > Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server". It seems like it is though? Servers need a way to handle authorization so they presumably need accounts. With a simple protocol, accounts map 1:1 to identities as far as the software and protocol are concerned. If you make a new account then you also make a new "identity" from the perspective of the software. The obvious way to solve that is to map any number of accounts to one (or possibly multiple) identities, where an account is the thing the server is concerned with and an identity is something else such as a private key. There's an additional question about the mechanisms for account creation and authentication. Maybe you don't want to maintain an email and password based login for a long list of accounts that are each tied to the same backing identity. There are multiple approaches available there as well, from oauth providers to public key based authentication possibly including things like cross signing.
- eternityforest 5y ago
  It's not about having multiple accounts, it's about the fact that federation is a bit meaningless when only a megacorp can run a server. Using a small server is just asking to lose everything when it goes away, and small things come and go all the time. Porting one account to a new server(Or better yet not tightly binding it in the first place) is essential.
  - rglullis 5y ago
    > Or better yet not tightly binding it in the first place Yeah, I agree. As I repeated elsewhere on this thread: having your own domain is the most straightforward way to guarantee that you can port your identity. But this is a separate problem from this idea of multiple "accounts". This is mostly from Mastodon's weird culture where people make this association between themselves and the in-groups from the instances. I wrote about that on my blog [0] https://raphael.lullis.net/federations-and-identity/ https://raphael.lullis.net/federations-and-identity/
d110af5ccf 5y ago
> Twitter's discovery is massively better Do you mean recommendation algorithms, or just the number of users ie network effects? > My "identity" was not portable between instances Your identity isn't portable between email servers either. Or between HN and Reddit. Isn't that part of what Keybase is about? I can imagine a couple ways of achieving this but it runs into a number of thorny issues regarding namespaces. Regardless of the approach taken truly portable identities would require lots of refactoring of lots of software in a FOSS ecosystem with fairly limited developer resources available. Merely linking identities should be much easier but still each piece of software has to support it. Simpler just to link to your other accounts in your bio the same as on any other website.
- leetbulb 5y ago
  > Isn't that part of what Keybase is about? was

rglullis 5y ago

> My "identity" was not portable between instances (that's different from user on Network A interacting with user on Network B), also no easy way to link multiple instance identities That is by design. It's a federated system! Just like you don't need multiple phone numbers to talk with people in different networks, or different email addresses depending on the recipient, you don't need different identities to communicate with different servers. Unless you want to keep your identities separate, there is no point in having multiple accounts.

d110af5ccf 5y ago
> Unless you want to keep your identities separate, there is no point in having multiple accounts. Until an instance goes down either temporarily or permanently and it was your only account. Then you'll wish you'd had a few extras. How many email addresses do you have? From how many independent providers? Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. In fact they already don't, a single identity already commonly has multiple accounts. The software just isn't aware of this fact and has no standardized way to communicate it.
- rglullis 5y ago
  > Until an instance goes down either temporarily or permanently and it was your only account. That's a technical problem, but not a UX or system design one. If a server goes down, my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one. > Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server". In any case, I totally understand the use case and I tried to get the Pleroma devs to focus on this idea as well: https://mastodon.communick.com/@raphael/106825107786781891 https://mastodon.communick.com/@raphael/106825107786781891
  - d110af5ccf 5y ago
    > my backup account is only going to allow me to keep participating, but it is not going to save the conversations I had on the lost one. The same issue exists for other services including email, irc, and matrix. The obvious simple and immediate solution is to retain copies of things you care about locally instead of expecting a particular service to stick around forever. With email this used to be standard practice before the rise of webmail. Even now most desktop clients sync to and retain a copy of everything on the local device. > > Accounts aren't portable but there's no inherent reason that accounts need to map 1:1 to identities. > Again, you are talking about identity portability, which is not the same as "creating one different identity for each different server". It seems like it is though? Servers need a way to handle authorization so they presumably need accounts. With a simple protocol, accounts map 1:1 to identities as far as the software and protocol are concerned. If you make a new account then you also make a new "identity" from the perspective of the software. The obvious way to solve that is to map any number of accounts to one (or possibly multiple) identities, where an account is the thing the server is concerned with and an identity is something else such as a private key. There's an additional question about the mechanisms for account creation and authentication. Maybe you don't want to maintain an email and password based login for a long list of accounts that are each tied to the same backing identity. There are multiple approaches available there as well, from oauth providers to public key based authentication possibly including things like cross signing.
eternityforest 5y ago
It's not about having multiple accounts, it's about the fact that federation is a bit meaningless when only a megacorp can run a server. Using a small server is just asking to lose everything when it goes away, and small things come and go all the time. Porting one account to a new server(Or better yet not tightly binding it in the first place) is essential.
- rglullis 5y ago
  > Or better yet not tightly binding it in the first place Yeah, I agree. As I repeated elsewhere on this thread: having your own domain is the most straightforward way to guarantee that you can port your identity. But this is a separate problem from this idea of multiple "accounts". This is mostly from Mastodon's weird culture where people make this association between themselves and the in-groups from the instances. I wrote about that on my blog [0] https://raphael.lullis.net/federations-and-identity/ https://raphael.lullis.net/federations-and-identity/

d110af5ccf 5y ago

> Twitter's discovery is massively better Do you mean recommendation algorithms, or just the number of users ie network effects? > My "identity" was not portable between instances Your identity isn't portable between email servers either. Or between HN and Reddit. Isn't that part of what Keybase is about? I can imagine a couple ways of achieving this but it runs into a number of thorny issues regarding namespaces. Regardless of the approach taken truly portable identities would require lots of refactoring of lots of software in a FOSS ecosystem with fairly limited developer resources available. Merely linking identities should be much easier but still each piece of software has to support it. Simpler just to link to your other accounts in your bio the same as on any other website.

leetbulb 5y ago
> Isn't that part of what Keybase is about? was