Proposal to integrate Cabal with Aether P2P

[benhylau]

I have been investigating this with @nehbit and got some early help from @cblgh on #aether on cabal://1eef9ad64e284691b7c6f6310e39204b5f92765e36102046caaa6a7ff8c02d74 and he suggested that I make a ticket here to start an open discussion. Well... that research has turned into this long post of how I understand the two protocols/apps compare and what a potential Cabal chat integration into Aether P2P could look like.

What is Aether?

Aether P2P is an open-source peer-to-peer application that creates a flood network for ephemeral communication, supporting subreddit-like communities with a distributed opt-in moderation system.

Aether Pro is Aether for private teams, a subscription-based service based on server-client architecture, with end-to-end encrypted communication and can be hosted on-premise in an organization's local network.

Background

Aether P2P and Pro are primarily built for asynchronous communications under the belief that real-time chat as a primary mode of interaction is hugely disruptive to focused tasks and drains our mental energy. However, there are certain tasks where synchronous chat is desirable, and just as we have meetings, we can use time-scoped chat for specific tasks, and so a server-client implementation of chat was added to Aether Pro to make it a fully-fledged team communication app.

In Aether Pro, the Backend on the server pushes chat messages to the Frontend on a user device in real-time. However, Aether P2P, as a peer-to-peer system, does not have servers. Both the Backend and Frontend live on the user device and sync with network peers periodically. This makes real-time chat impossible.

Since Aether P2P and Pro share more or less the same Client, the user interface for chat is already built. We are investigating integration of a peer-to-peer chat into Aether P2P, so public communities can also enjoy the same chat feature as Pro users.

To determine requirements for this feature, or whether a real-time chat is desirable at all, we asked the Aether community on this Aether thread. Here is a summary of what we would like to answer:

• Privacy of network communications (e.g. IP address sniffing)
• Privacy of messages (e.g. "bridging" to a community outside of aether identities)
• Moderation model (e.g. does the board moderation carry over to chat?)
• Third-party software bloat (e.g. matrix-p2p, cabal, and their upgrade timelines, etc.)
• Centralization points (e.g. irc server)
• Ephemeral history

Network comparisons

Here I hope to compare the Aether with Cabal networks based on the above criteria.

Privacy of network communications

An Aether P2P node syncs with many peers "in its neighbourhood" every minute, and it is not easy to figure out origin IPs of the messages.

Cabal is based on kappa-db and it is unclear how easy it is to figure out origin IP of messages based on its sync model, which I imagine consists of more direct dailing to content origin, with some relaying where needed.

Privacy of messages

In Aether P2P, all messages are public. There is no direct message support.

In Cabal, it is theoretically possible to do private messages from one identity to another using private-box.

Moderation model

Every Aether P2P node may keep data of the entire network, and the participant has authority to override any moderation applied to their view. Therefore, moderation is opt-in and subjective.

Any participant who enables a mod flag from their application settings can be a moderator. The mod actions they take are only applied to people who accept them as a moderator. This means anyone can emit mod action signals, but only those who choose to accept them see its effect applied to their view.

While there is no global moderator for any community, there is the concept of a default moderator for a community, where most participants of that community will accept its creator's moderation actions. They may however choose to locally disable the default moderator, in which case the actions emitted by that moderator will not apply to their view.

There is also an election system for default moderators, which has not yet been implemented.

When you are not a moderator, you can report posts:

When you are a moderator, you can delete posts:

All of which, of course, can be overridden by the end user due to the subjective moderation model.

Cabal moderation is a subjective moderation system that shares many similarities with Aether. A participant opts in to an admin and mod key to censor their own stream. There are remaining issues with a thread on purging messages from banned users, something that Aether cannot do.

Third-party software bloat

Aether P2P consists of Backend, Frontend, and Client, mostly written in Go with JavaScript and Electron for Client.

Cabal is written in JavaScript and relies on kappa-db and hypercore.

This is a bit of an issue as Aether does not have a JS execution environment. There is a GUI thread that runs JavaScript, but it has no access to the primitives, and it's only one single thread. Attempting to do any calculation or importing something sizeable in our GUI thread with JavaScript would quickly make Aether start to feel like other Electron apps in terms of speed and memory leaks.

If we are to go with this, we will need to find a way to ship a cross-platform JS interpreter, which means we need to add Node.js to our entire build pipeline for each platform and architecture.

It would be great if Cabal had a C, Rust, or Go library, or anything else that conforms to the C Foreign Function Interface. Does something like that exist?

Centralization points

Aether P2P relies on central nodes to bootstrap when first installed, but after that it can sync with peers independent of any central server. As long as it can sync with one peer, it can replicate everything.

Cabal is based on kappa-db and can work in off-Internet settings as long as cabal swarm peers can reach each other.

Ephemeral history

Aether P2P nodes are configured to keep a minimum of 2-week history, and only up to 6 months as capacity allows. While individual participants may hold on to history for a long time, the flood network itself "forgets" after 6 months.

In Cabal, history in a multifeed is generally permanent, but sparse replication (light clients) and ephemeral messages are being discussed.

Potential integration

I understand that Cabal currently runs into performance limits once a single cabal nears 500 identities, but there can be as many cabals as you want as long as individually they do not reach that number of identities.

While the Aether P2P realm (the universe of all users) have thousands of users, the largest community (like a subreddit) has about 400 users. So in theory, we can map each community into its own cabal, and participants of that community can swarm on that same multifeed.

Each Aether participant has an identity and signing key, which needs to be mapped to a Cabal participant key.

Since the Aether moderator status is just a local state, not a global state, we may be able to extend this to moderate Cabal chat messages just by hiding chat content in the local view based on the local decisions made on the client. We do not have to use Cabal's moderation system at all.

[okdistribute]

@benhylau Amazing work on this overview, thanks so much -- I had looked into Aether in the past briefly, but this was really helpful to get up to speed on it's core assumptions and design decisions.

It would be great if Cabal had a C, Rust, or Go library, or anything else that conforms to the C Foreign Function Interface. Does something like that exist?

There is an ongoing rust implementation of hypercore which would be the first step to a cabal client in another language. https://github.com/datrs. There is funding currently in line for it through an NLNet grant which will likely show results this winter.

Implementation of hyperswarm, kappa* and multifeed on top of this in rust is also possible but there is not money allocated that I'm aware of, although plenty of volunteers who are interested in pushing it forward.

Cabal is based on kappa-db and it is unclear how easy it is to figure out origin IP of messages based on its sync model, which I imagine consists of more direct dailing to content origin, with some relaying where needed.

One could theoretically build a bot client that connects to the network & dht to figure out which IPs are sending which messages with real-time analysis. There is ongoing interest from @substack to integrate cabal with i2p, which could make privacy better.

[nehbit]

Thank you @benhylau!

One more possible option — does Cabal have a local API? For example, in Aether, when the client is running on the local machine, it exposes 1 API to network and localhost (Mim) in HTTP, 2 APIs on only the localhost, the backend and the frontend API, in GRPC. These APIs are accessible to other apps in the same computer that want to integrate with Aether, since they can query at whichever level they desire. (These APIs only return public data.)

Is there a similar thing for Cabal? Maybe a more elegant implementation would be something like having a 'Cabal' switch on Aether. If you flip that on and you have Cabal installed / running on your system, Aether could make requests to the Cabal port (127.0.0.1:XXXXX) on the local machine, if such thing exists with Cabal.

That would mean we would be using the app directly, so that your improvements would directly stream in as the users update their Cabal apps, and we would not be shipping an entire, potentially redundant copy of Cabal if the user already has Cabal installed. It would also render the programming language compatibility issues moot, since they would be talking over HTTP.