Discuss theoretical solutions to a fully distributed chat application with me

Ecosystem
1

This is what I am working on right now and could use some inspiration from the community.
i’ll break it down into steps:

  1. Sending/receiving messages. Probably the easiest part, use pubsub. Also encrypt and sign messages, should not be a challenge. The topic for pubsub could be the concatenation of the two participants, hashed.
  • Challenge number one: what if the recipient is not online? What I came up with is that upon receipt a confirmation message is sent back. If no confirmation was received send again. Other approach is to store the unreceived message. Then require each client to announce themselves to the network whenever they come online, then when such announcement was received by the sender, resend the message. But in this case, what if the sender has gone online?
  • Challenge number two: NAT problems, what if some one is sitting behind a router? I’m sure there already is a solution to this, but I haven’t had the time to look into it.
  1. Message storage: like any other chat app I want to be able to see past conversations. As long as the user uses just one device, this is pretty straight forward, save to disk, load from disk. Probably symmetrically encrypted. But what if later I want to log in from some other device? Then I need to fetch my past messages from my original device.
  • Solution one: use FileCoin storage. I don’t want this app to cost money (FIL), so, no.
  • Solution two: I could store my data on IPFS but I don’t suppose it will stay there very long as without incentive it will be garbage collected. Pinning services cost money, AND they are kinda centralized. So no.
  • Solution three: store data on Ethereum blockchain as a smart contract. Again, costs money, so no good.
  • Solution four: friend-to-friend ‘subnetworks’. I store your data as long as you store mine. The idea here is that there is no need for complicated, trustless verification schemes(PoS, Pow, PoSt etc etc etc), the trust is simply the trust in friends that they will host your data in exchange for you hosting theirs. From a technical point of view this can be done using OrbitDb, where friends replicate each other’s databases. This of course doesn’t guarantee 24/7 data availability, it is possible that all nodes that have my data replicated are offline. but, the more friends the better.
  • Solution five: don’t bother. As in, realistically is this even a use case? How often does one find themselves logging in from some random device? Usually it’ll be like, laptop, work device, smart phone and that’s it. Occasionally exchange one of these for a newer one. My point is that if we are trying to login from some new device, chances are that we have another device on us (usually the smart phone), and therefore we can move our data (past messages) from one to the other. Like for example, encode the OrbitDB address into a QR code, scan it with the smart phone, and replicate the DB. Or, encode a random topic string into a QR code, scan it with the mobile phone, then send the DB address over that topic, and then finally the new device replicates the DB.
  • If you have any better ideas PLEASE let me know.

  1. Identity: How are users identified. This usually involves some unique identifier such as an email, a phone number, a username guaranteed by the server to be unique and so on. For the first two: I advocate for anonymity so no, for the third one, we have no server so yeah, can’t be done.
    A solution I came about is seeded key pairs: instead of using a truly random number for asymmetric key generation, use a seeded CSPRNG.
    The seed would be obtained by passing a passphrase to a KDF like Scrypt, with the username as salt. This way, the same private/public key could be replicated on any device, without having to import the key from another device, provided the user remembers their username and password.
    It could be argued that this is less safe than truly random generated private keys, but I think it is just as safe as any other auth service right now: if somebody learns my username and password I lost my privacy.
    I imagine verification of a public key belonging to a person would be done in-person, there is no better method I am aware of.
    Of course, as mentioned in the section above, if I use solution five for syncing data between devices, might as well send the keypair over as part of that same process.

  2. Finally, is it even worth it? To me it is a cool experiment, a chat app with no central choke point, for the sake of it. Nevertheless, surely it will be slower, data might not be available at times and so on

2

Are you awake of Berty? IFAIK they do all of that and more!

3

The solution four. The more friends — the better. And also there are friends of the friends. I’ve written a paper about the possible advantages of a web-of-trust based approach to dynamic services on top of IPNS, see A preliminary discussion of the “Workswap” protocol . (The paper itself sometimes needs a delay to be loaded when it’s out of the gateway’s cache, but it’s pinned on my node.)

4

Yes, I did come across it, though never went into details as to how exactly it works, and how it achieves device independent access to your data. If anyone knows more about and could sum it up, it would be much appreciated.

5

I didn’t delve deep either :stuck_out_tongue: But if they store data on IPFS seams like they could do it maybe?

6

A reasonnably short read is berty’s description of the protocol. It’s not specs per say so it’s high-level enough to give a good overview.

7

Oh yes that’s the stuff. Thanks!

1 Like
8

If you are interested, I would invite you to telegram and chat with me, we can spend a couple days talking back and forth about all the points you’ve made, I’ve been doing something similar myself, because I am kinda reinventing the wheel for fun

9

I haven’t read all the other comments and I don’t really understand enough of all this to comment with certainty, but … could you try something like this:

  1. The 2 or more users involved in a chat each have their own chat ID ( from whatever source )
  2. They form a contract to exchange chat messages
  3. So long as they’re online, their private copy of the chat so far is available to other members of the chat
  4. Which means that until someone goes offline, they will likely have a store of the entire chat, which is made primarily of small and rather simple text file components
  5. So when someone goes offline, everyone else continues to store that chat, until all of them go offline, at which point, the last person off has the most complete version of the chat, and the contract records that final state
  6. When someone comes back online who doesn’t have a complete version, checking with the contract will tell them an update is required, and this is the point at which you need other users to be able to update the chat for you even though they weren’t involved and the chat is encrypted to keep it private
  7. So this can be solved either through a desktop / mobile app., where people using it agree to keep small parts of other peoples files online in exchange for using the app … OR where rewards are offered via Filecoin, which incentivises those with large amounts of storage to hold many chat files and contracts in a permanent online status
  8. The chat up to the last point of update can always be viewed in an offline form, even if no one is online to update it to the latest version, but leaving the chat shouldn’t necessarily mean the app stops updating itself as a background operation, so as long as users allow the application to update in the background and they don’t switch the device off or go offline, they actually won’t need permanent online storage
  9. Thus where 8 above is unavailable as an option, THEN ( and only then ) do you actually need to worry about permanent online storage via some third party/parties, and this could be made by the difference between a free version of the app ( no guarantee of permanent storage ), and a paid version ( guarantee of paid permanent storage ).
  10. On top of that, you aim to create a corporate / enterprise version of the software, so that large companies will sponsor the development of specific code required for them to integrate this with their existing systems and processes, giving them security and privacy of internal communications, even when people are operating outside their network and not even via a VPN … I would think some companies would happily offer top dollar for that
  11. Set up the development as a cooperative so that there’s no management executives, no one draining resources through extreme salaries, nor perverting the course of development … thus costs are kept low, there’s wages for people involved, it stays free to use for most functions, and eventually any cost of operation is subsidised for the average user by corporate users

How does that sound?

10

we have a discord group that I’ve found out a couple days ago, we talk about all kinds of stuffs from helps to ideas.
link : ipfs