[colejohnson66]

Serious question: how would you decentralize something like a messaging app? Don't you need /something/ to facilitate routing? Or do you use some kind of public-private key encryption on a blockchain? But then how do you get someone's public key if they're offline? And why would you want to store a blockchain of everyone's encrypted messages? To get around that, you'd end up with some centralized server storing the whole blockchain and you only receiving yours? But then you're back at the problem Bitcoin has: You want a decentralized blockchain, but people don't want to store 73,745 megabytes[0] of other people's transactions they don't care about. Bittorrent's DHT system still relies on a few "kickstart" servers to send you a list of peers who can send you a list of peers...

[0]: https://blockchain.info/charts/blocks-size (26 Jun 2016, 0519 UTC)

[zeeveener]

In regards to decentralizing something like a messaging app, there are a couple interesting approaches.

1) Have "tracker" servers set up around the world. The App needs to know at least one of the IPs, preferably all, in order to get a list of Peers it can connect to. This is still considered "decentralized" so long as none of the "trackers" is considered a "master" over the others.

2) Have UserA manually enter the IP of another UserB. Then, UserB tells UserA all of the Peers it knows about, which UserA will then connect to, and so on and so forth. This approach can quickly get out of hand unless there is some sort of limit on how many peers a User can be connected to at once. That's up to the developer (or possibly user) to decide.

Theoretically, as long as one Peer is alive and doesn't forget the list of other Peers it has been told of, the network will never completely shut down. Even if it does, however, the network can "start back up" again, but there may be cases of "subnets" within the P2P network if no peers from one subnet ever know of peers from another subnet.

In regards to the actual chat functionality, it's very simple. As long as you can preserve consistency between peers (which is its own subject), it's relatively easy to have each Peer keep a copy of the current chat. Even if the chat is between >2 Peers.

There are intricacies to this, but it's not actually that difficult. It's a lot more complicated to design, but once the groundwork has been laid, it can sustain itself for the most part.

[colejohnson66]

> 1) Have "tracker" servers set up around the world. The App needs to know at least one of the IPs, preferably all, in order to get a list of Peers it can connect to. This is still considered "decentralized" so long as none of the "trackers" is considered a "master" over the others.

How is that not decentralized? I really don't see how. You'd need /someone/ to maintain that list of tracker serves.

[desiderantes]

Well, like this: https://tox.chat

[lucaspiller]

One thing I don't like about most modern decentralised chat services is their main concern seems to making something perfectly secure and private. I agree that's a good goal to have, but right now I'd just like something decentralised and open source, as simple to use as Whatsapp, that isn't owned/controlled by a single megacorp.

[imrehg]

Bitmessage https://bitmessage.org/ no blockchain, though, just relatively short-lived messages, works pretty decentralized (though it is still sort of solution in search of a problem, even if I'm using it myself for a long time - nothing useful, mind you)

[Cozumel]

The site is currently down https://paul.kinlan.me/serverless-sync-in-web-apps/ but there was a good tutorial here on how to build a serverless message app.

[dingo_bat]

>Serious question: how would you decentralize something like a messaging app?

Like email. Let everyone host their own chat server. Pass messages around to the correct server and let it forward it to the user's device.

[zanny]

Which are what XMPP and Matrix do. Both have username / server routing and for Matrix at least history propagates between participant host servers.

Or you go the Tox / Ring route with a DHT of users and cut out the server alltogether, but the server part is pretty much always necessary for "pretty usernames". Tox has been basically dead in the water for quite some time because they have no effective DNS for users that is universal to all the Tox apps with multiple competing implementations.

My personal takeaway is that if you are going to have a server you should take full advantage of it like Matrix does, because Matrix mobile clients can be push-notify based and not need to always be online to get messages (though Tox et al have ways around that, they are all dependent on storing messages locally to the destination in the DHT, and most users do not want to have to cache other peoples messages).

[colejohnson66]

But how do you know who to pass around to? Email works by looking up an IP address from the DNS. Sure DNS is distributed, but it all is "centralized" around the 7 root DNS servers.

As I said in my original post, it sounds similar to how Bittorrent's DHT works; you'd still need a "kickstart" server to send you a list of peers. Sure, you can hardcode a list of peers, but hardcoded stuff isn't decentralized. Someone has to maintain that list.