3 ms·

> Why would you say the federation is snake oil? With federated services your are still just user@host, completely under the control of whoever owns host. Furt

> Why would you say the federation is snake oil? With federated services your are still just user@host, completely under the control of whoever owns host. Furthermore the federation aspect is completely optional, if host decides to blacklists some other hosts, there is nothing you can do about it. So I don't see the advantage over the Twitter, Facebook and Co., when everything that makes federation special can be taken away at any moment. Without some public-key crypto or something that allows you to move your identity to another server or better yet, never exist on any specific server to begin with, I just don't see the point. In general, I think the only way to build a "Libre Cloud" is by making the cloud part as stupid as possible. Have the actual app run completely on the client, use the cloud just as dumb object store with little to no awareness of what it is serving.

southerntofu 5y ago
> can be taken away at any moment Not exactly, no. It can be taken away when your server operators decide it. But in the federated model, we go with explicit trust relationships and non-profit, community-operated hosts so that's not a problem in practice. In fact, i'm glad my server operators actively defederate from neonazi-friendly nodes, so that i don't have to deal with them... just like i'm glad my email operator validates DKIM and uses rate limiting to prevent spam. > some public-key crypto or something that allows you to move your identity That's a very interesting approach. It's been implemented in the ZOT protocol (Hubzilla ecosystem), and has been talked about in the Jabber/XMPP and Matrix ecosystems too. I'm excited for that future, if we can come up with an interoperable spec across protocols. > use the cloud just as dumb object store with little to no awareness of what it is serving That's an interesting approach indeed, and i'm interested if you have more resources/links on that. I've been thinking for a while about reducing the difference between federated and P2P services, like how servers could help you seed your content, and/or act as inbox for when you're offline. I've started drafting a blogpost in that direction a while back.. nothing much in there yet but if it can be of interest to you: https://ttm.sh/tHG.md https://ttm.sh/tHG.md
pessimizer 5y ago
> With federated services your are still just user@host, completely under the control of whoever owns host. Furthermore the federation aspect is completely optional, if host decides to blacklists some other hosts, there is nothing you can do about it. So I don't see the advantage over the Twitter, Facebook and Co., when everything that makes federation special can be taken away at any moment. These seem like advantages to federation. You can choose your masters, and you can choose another master (and they can choose to get rid of you) at any time. I don't think that the advantage of federation over centralized services is that you can say and do what you want and everyone has to listen to or service you. It's that you have more options than one. Of course, in the worst case, most nodes could federate into an exclusionary cartel controlled by a single, well-financed organization. But that means that the worst case for federation is the only case in the current situation. ----- edit: I do think that the major thing missing from the web 2.0 user-provided content internet are tools to facilitate democracy and self-governance. With properly done tools and ownership structures, maybe the users can actually own their accounts, and have as much of a say in how their node was run as you would expect in an organization of peers.
- southerntofu 5y ago
  > You can choose your masters, and you can choose another master (and they can choose to get rid of you) at any time. That's only if your federated protocol supports account migrations (usually with some form of crypto-identity). This was pioneered as part of the Hubzilla ecosystem and ZOT protocol. Nowadays there are efforts to port this approach to ActivityPub/XMPP/Matrix, we'll see where that goes! Of course it's all easier if everyone owns their domain name and you can migrate "transparently". But the tooling for giving away free, pseudonymous domains is limited so far (afraid.org, netlib.re, eu.org..).

southerntofu 5y ago

> can be taken away at any moment Not exactly, no. It can be taken away when your server operators decide it. But in the federated model, we go with explicit trust relationships and non-profit, community-operated hosts so that's not a problem in practice. In fact, i'm glad my server operators actively defederate from neonazi-friendly nodes, so that i don't have to deal with them... just like i'm glad my email operator validates DKIM and uses rate limiting to prevent spam. > some public-key crypto or something that allows you to move your identity That's a very interesting approach. It's been implemented in the ZOT protocol (Hubzilla ecosystem), and has been talked about in the Jabber/XMPP and Matrix ecosystems too. I'm excited for that future, if we can come up with an interoperable spec across protocols. > use the cloud just as dumb object store with little to no awareness of what it is serving That's an interesting approach indeed, and i'm interested if you have more resources/links on that. I've been thinking for a while about reducing the difference between federated and P2P services, like how servers could help you seed your content, and/or act as inbox for when you're offline. I've started drafting a blogpost in that direction a while back.. nothing much in there yet but if it can be of interest to you: https://ttm.sh/tHG.md https://ttm.sh/tHG.md

pessimizer 5y ago

> With federated services your are still just user@host, completely under the control of whoever owns host. Furthermore the federation aspect is completely optional, if host decides to blacklists some other hosts, there is nothing you can do about it. So I don't see the advantage over the Twitter, Facebook and Co., when everything that makes federation special can be taken away at any moment. These seem like advantages to federation. You can choose your masters, and you can choose another master (and they can choose to get rid of you) at any time. I don't think that the advantage of federation over centralized services is that you can say and do what you want and everyone has to listen to or service you. It's that you have more options than one. Of course, in the worst case, most nodes could federate into an exclusionary cartel controlled by a single, well-financed organization. But that means that the worst case for federation is the only case in the current situation. ----- edit: I do think that the major thing missing from the web 2.0 user-provided content internet are tools to facilitate democracy and self-governance. With properly done tools and ownership structures, maybe the users can actually own their accounts, and have as much of a say in how their node was run as you would expect in an organization of peers.

southerntofu 5y ago
> You can choose your masters, and you can choose another master (and they can choose to get rid of you) at any time. That's only if your federated protocol supports account migrations (usually with some form of crypto-identity). This was pioneered as part of the Hubzilla ecosystem and ZOT protocol. Nowadays there are efforts to port this approach to ActivityPub/XMPP/Matrix, we'll see where that goes! Of course it's all easier if everyone owns their domain name and you can migrate "transparently". But the tooling for giving away free, pseudonymous domains is limited so far (afraid.org, netlib.re, eu.org..).