Additional features decentralized services needs - practical web3 ep.2

=> home

I've been thinking more about what can I build with GNUnet. To be particular I started by thinking about how I can replicate existing service on GNUnet. See my previous post about properties I think a decentralized service needs in order to be useful and somewhat robust. After more mind storming. I think there's more that's needed.

=> My previous post where I proposed a decentralized service.

First I tried to imagin an email like service on GNUnet and have it actually be better then clearnet. I mean that by, getting SMTP to "work" over GNUnet is easy. Just use CADET as a TCP replacement. However, this does not buy us much in terms of usability or privacy. Users still are relying on a single service provider; if they go down everything the user has disappears. And the service provider still knows the user's peer ID (IP address of the GNUnet world). The only benefit this have is CADET can route traffic under a very restrictive environment.

Clearly proxying clearnet protocols over GNUnet won't work. We need designs native to decentralization.

Something like libgnunetchat works better. It is a fully decentralized chat system native to GNUnet. However, unlike SMTP-over-GNUnet, libgnunetchat does not replicate chat history and uses your Egos (virtual identities) as user accounts. Thus you can't 'login' to the same account on multiple devices, nor retrieve old messages, at least not without some extremely complicated setup.

=> libgnunetchat: A client-side library for applications to utilize the Messenger service of GNUnet.

This might be more secure as it enforces separate identity on different devices. But is also makes most applications borderline unusable for most daily uses. Just imagine that you can't check your work email when you are outside in a coffee shop talking to a client. From this observation, I think 2 additional features any decentralized services need to provide:

• Able to "login" to the same user from different nodes
• User data must be accessible from different nodes

Some sort of layer 2 system must be developed to support the above features. Supporting them also creates a new and very complicated issue:

• Split brain/consistency concerns (CAP theorem, apparently we need availability as devices and and will go down. We have to pick partition tolerance or consistency)

Fortunately there's prior work. GNU Jami is a decentralized messaging application (not part of GNUnet). It uses OpenDHT to negotiate a NAT punching tunnel to other users and other devices logged in with the same user account. Then conversations are stored locally as a git repository. When a deceive previously is offline goes online. Devices merge their conversations. This works quite well. But scalability is a bit limited. Complete history synchronization requires O(N^2) merges. Though I believe it's possible amortize this down to O(N log N) under sane usage patterns. This is however still worse then the O(N) with centralized services.

That solves the synchronization part and replicating it on GNUnet is almost trivial. For a layer 2 user. We publish the Peer ID encrypted with the user's private key under the key of the user's fingerprint onto the DHT. Then when synchronization is needed. Just go to the DHT and find the list of nodes that is logged in as the l2 user.

The problem is where to store the user data. There's 2 obvious route

• Store on device logged in as said user
• Encrypted, sharded and share it publicly

Personally I think the 2nd option will not work for many reasons. 1 that people do not want to do something that won't benefit them directly. Most people (especially lite users) will feel it to be heavy weighted and tend to delete data they don't use. 2nd that GNUnet want to be built in a way that each user contributes more then they take from the network.

The 1st option have it's problem tho. This means when accessing data belong to a user, the user must have at least one device online. This may not be the case for social media applications. Where users from half an earth away may access another's home page. Thus this approach is limited to where only the user is interested in their own data. Ex: Instant messenger, email, decive synchronization.

=> =

Welp. That's enough rambling for today. Identified a few limitations/stuff a decentralized application must have. I shall go back and work on my TLS refactor for Trantor.