The only shot these decentralized networks/social things have of accomplishing their dream is to ditch federation and deploy true P2P via desktop/mobile apps. Think old Skype.
Any server requirement more than a non-proxying NAT hole puncher is a death sentence for decentralized services targeting mainstream users (unless you get big investments into a handful of quasi-centralized servers). The network needs to run on a handful of techie users fronting $10/month in server resources, or it just won’t scale.
People can install apps, they can’t manage servers.
That can be sent around via email as well. Likes can be implemented as a CRDT, so people may not have a consistent view but it can become consistent over time.
You don’t have to use their personal email addresses, they can create free ones on gmail or wherever. I’m just saying to use email as the underlying protocol.
That doesn’t help. Even if it was a randomly chosen email, the sender and receiver are in the clear for the network to see and construct the social graph. Even if you rotate emails it’s probably still reconstructible.
Not all federation has expensive costs. Pleroma can run on a raspberry pi. The Pleroma/Mastodon/GNUSocial is around a million users right now, so I’m not really sure that argument holds. Being said I would also love to see “Old Skype” apps. Ring.cx is a good example of this working well. Decentralization and Federation don’t have to be mutually exclusive and we should stop thinking about this space as an either / or.
This is the approach I took with Firestr, Just download the app and run it. Only server thing is a non-proxying NAT hole puncher. I took this approach because that’s exactly what i thought, no user is going to run a server, therefore has to be an all in one experience where you just run the app and go.
Isn’t Skype a bad example for “true decentralisation” (I am assuming you mean by this “distributed”), since a cenral server managed usernames, statuses and IP address communication (if I am not wrong)? Attempts to truly create P2P networks, lets take the standard example of IM/video chat, like Tox suffer from cryptic user names (ie. DHT codes), the need for both parties to be simultaneously online for messages to be sent and received and most of the time a “hacky” feel to the whole setup. The last issue could be avoided by good cooperation between a design/UX/UI and developer team, but I don’t see any way around the first two, without setting some absolute standards (eg. reference servers).
It works for certain use cases, for example firechat for physically manifested crowds or Tox for absolutely anonymous chat, but this doesn’t do what most people want, which has sadly always been what centralized systems are intrinsically good at: deferring responsibility to validated identities, transmit information and guarantee/promise operation from the users to some other instance, which is usually legally bindable.
I 100% agree. This is the approach we’ve taken with Peergos. You can create your account by running the desktop version, or you can sign up on our central server (or anyone elses), but your identity, social graph, etc. has nothing do do with that choice of server. All that decides is where, initially, all your data is stored. Through the magic of IPFS it’s accessible from anywhere - we only need at least one server to store each users files to guarantee no loss.
Moving an account you created on our server to your own (desktop or cloud instance) is trivial and doesn’t lose any data, metadata or social connections. This gives both a nice on-boarding experience, and also allows us to satisfy a wide range of threat models. The average user can just log in to a server via a web browser exactly like facebook. More discerning users can run their own server, in the cloud or at home.
The relative difficulty of running your own as an absolute beginner
yes, it’s difficult. that’s because one has to know how things work to make them work. we have to get away from this “computers are easy!” thing. they aren’t, and everything that pretends to be easy has a trade-off (privacy seems to be the current thing). analogy: cars (even bikes) are seldom built by their owners, the trade-off for them being easy and comfortable to use are high repair costs, as things are more complex. technology isn’t easy, even if everybody wants one to believe that.
The eventual centralization on top of the most well-run versions (like Matrix)
there will always be bigger instances. reasons for running an own instance are either that you find it interesting or that you don’t trust any of the existing ones (or both). one doesn’t have to federate just because it’s possible. the important thing is that it is possible.
A matrix server isn’t like “freenode”. Matrix itself is like freenode. There’s no advantage you get by choosing one matrix server over another, you can join all rooms regardless.
IRC could have been a million small communities running their community-based chatrooms. Instead, we have 10-100 popular IRC servers, with Freenode being the most well-known among casual techies.
What seems to be different (and what I find very interesting about the IRC server structure) is that freenode isn’t one server, but in itself a network of different individual IRC servers, “sharing” chat rooms, users and messages amongst each other. The trade of is (at first) protocol given IDs, one only has “nick names”, but in practices this can be made up by having a (centralised, to be fair) NickServ bot allowing or denying entrance into certain chatrooms.
This is massively different from other Federalized/Decentralized networks, where each server has it’s own “strong” identity (for example @gmail.com or @mstdn.io), while who you are connected to totally becomes forgotten and irrelevant with these “weak” identity systems, like IRC or Electrum servers within the Bitcoin network.
It seems very interesting, but I haven’t read too much about this difference, at least from my “pop research” perspective.
The only shot these decentralized networks/social things have of accomplishing their dream is to ditch federation and deploy true P2P via desktop/mobile apps. Think old Skype.
Any server requirement more than a non-proxying NAT hole puncher is a death sentence for decentralized services targeting mainstream users (unless you get big investments into a handful of quasi-centralized servers). The network needs to run on a handful of techie users fronting $10/month in server resources, or it just won’t scale.
People can install apps, they can’t manage servers.
People should just implement these things using email as the communication substrate. The servers are already out there and federated.
This is the conclusion I came to as well. The “liked by who” is metadata that would have to be stored somewhere though.
That can be sent around via email as well. Likes can be implemented as a CRDT, so people may not have a consistent view but it can become consistent over time.
If you’re emailing your friends then you’ve immediately exposed your social graph.
You don’t have to use their personal email addresses, they can create free ones on gmail or wherever. I’m just saying to use email as the underlying protocol.
That doesn’t help. Even if it was a randomly chosen email, the sender and receiver are in the clear for the network to see and construct the social graph. Even if you rotate emails it’s probably still reconstructible.
Sure. If that’s something you want to hide then maybe that’s a problem for you.
Not all federation has expensive costs. Pleroma can run on a raspberry pi. The Pleroma/Mastodon/GNUSocial is around a million users right now, so I’m not really sure that argument holds. Being said I would also love to see “Old Skype” apps. Ring.cx is a good example of this working well. Decentralization and Federation don’t have to be mutually exclusive and we should stop thinking about this space as an either / or.
This is the approach I took with Firestr, Just download the app and run it. Only server thing is a non-proxying NAT hole puncher. I took this approach because that’s exactly what i thought, no user is going to run a server, therefore has to be an all in one experience where you just run the app and go.
Isn’t Skype a bad example for “true decentralisation” (I am assuming you mean by this “distributed”), since a cenral server managed usernames, statuses and IP address communication (if I am not wrong)? Attempts to truly create P2P networks, lets take the standard example of IM/video chat, like Tox suffer from cryptic user names (ie. DHT codes), the need for both parties to be simultaneously online for messages to be sent and received and most of the time a “hacky” feel to the whole setup. The last issue could be avoided by good cooperation between a design/UX/UI and developer team, but I don’t see any way around the first two, without setting some absolute standards (eg. reference servers).
It works for certain use cases, for example firechat for physically manifested crowds or Tox for absolutely anonymous chat, but this doesn’t do what most people want, which has sadly always been what centralized systems are intrinsically good at: deferring responsibility to validated identities, transmit information and guarantee/promise operation from the users to some other instance, which is usually legally bindable.
I 100% agree. This is the approach we’ve taken with Peergos. You can create your account by running the desktop version, or you can sign up on our central server (or anyone elses), but your identity, social graph, etc. has nothing do do with that choice of server. All that decides is where, initially, all your data is stored. Through the magic of IPFS it’s accessible from anywhere - we only need at least one server to store each users files to guarantee no loss.
Moving an account you created on our server to your own (desktop or cloud instance) is trivial and doesn’t lose any data, metadata or social connections. This gives both a nice on-boarding experience, and also allows us to satisfy a wide range of threat models. The average user can just log in to a server via a web browser exactly like facebook. More discerning users can run their own server, in the cloud or at home.
True P2P generally isn’t too friendly with battery life and data caps.
yes, it’s difficult. that’s because one has to know how things work to make them work. we have to get away from this “computers are easy!” thing. they aren’t, and everything that pretends to be easy has a trade-off (privacy seems to be the current thing). analogy: cars (even bikes) are seldom built by their owners, the trade-off for them being easy and comfortable to use are high repair costs, as things are more complex. technology isn’t easy, even if everybody wants one to believe that.
there will always be bigger instances. reasons for running an own instance are either that you find it interesting or that you don’t trust any of the existing ones (or both). one doesn’t have to federate just because it’s possible. the important thing is that it is possible.
A matrix server isn’t like “freenode”. Matrix itself is like freenode. There’s no advantage you get by choosing one matrix server over another, you can join all rooms regardless.
What seems to be different (and what I find very interesting about the IRC server structure) is that freenode isn’t one server, but in itself a network of different individual IRC servers, “sharing” chat rooms, users and messages amongst each other. The trade of is (at first) protocol given IDs, one only has “nick names”, but in practices this can be made up by having a (centralised, to be fair)
NickServbot allowing or denying entrance into certain chatrooms.This is massively different from other Federalized/Decentralized networks, where each server has it’s own “strong” identity (for example
@gmail.comor@mstdn.io), while who you are connected to totally becomes forgotten and irrelevant with these “weak” identity systems, like IRC or Electrum servers within the Bitcoin network.It seems very interesting, but I haven’t read too much about this difference, at least from my “pop research” perspective.