Draft Service Message Broadcast protocol

[gnarea]

Overview

Offer the ability to broadcast signed, unencrypted messages to anyone interested in such messages, without the sender knowing who's interested. Potential applications include:

• Letro newsletters.
• Distributing the latest articles from news organisations.
• Software update notifications (just the notification, not the actual binary).
• Announcing PKI certificate revocations.
• Decentralised social networks.
• Enabling protest organisers to make announcements within a meshnet (see Draft "PoScatternet" binding to relay parcels via scatternets (Bluetooth meshnets) #46).

Technical design

This specification will extend Awala to support the Publish-Subscribe pattern, where:

• The publisher is an Awala endpoint, identified by their Awala private address (better privacy) or Vera id (better UX).
• The subscribers are zero or more Awala endpoints.
• The topic is determined by the publisher and must be tied to a specific Awala service.
• Each message is an unencrypted Awala parcel, with the sender being the publisher and the recipient being the topic.
• Each subscription filters messages produced by a specific publisher and/or matching a specific topic. If only the publisher is specified, the subscription must be limited to a specific service.

If we imagine a world where Twitter is an Awala service using this protocol, then every Twitter user is a potential publisher and subscriber. Following a Twitter user means subscribing to a publisher. Each tweet is a message. And there'd only be one topic in the whole service.

Awala Internet gateways will form a P2P network to propagate the messages. Private gateways will subscribe to topics on behalf of their endpoints via their respective Internet gateways, without disclosing which endpoint(s) require the subscription.

Avoiding hate speech and misinformation

We'll use a new PKI to avoid hate speech and misinformation at scale, in a decentralised manner.

The root certificates will belong to an "Oversight Board" (OB) that will set the policies that participants must adhere to. Each member of the OB will own a root certificate, and each of these will be included in the trusted key store of Awala-Internet Gateway providers like Relaycorp.

For an end user to broadcast messages, they'll have to be sponsored by an intermediate. The sponsor is a charity or company vetted by the Oversight Board; they get an intermediate certificate issued by a board member when they're accepted.

Sponsors get a lot of autonomy in determining their criteria to let people in, since the only requirement is that their sponsorees don't spread hate speech or misinformation. Some may require the real identity of their sponsorees, and others may accept anonymous users. Some may require a payment for the sponsorship.

Generally, the certificates issued by sponsors to end users should be short-lived when users are new, and subsequent certificate renewals will produce certificates that last longer. For example, a brand new user may get an initial certificate that lasts 3 days, and when it's automatically renewed, if they haven't broken any rules, the second certificate will last a week -- and so on.

Any member of the OB can revoke certificates issued to any user or sponsor, but sponsors can only revoke their own users' certificates. Gateway providers will monitor such revocations to drop messages signed with a revoked certificate, similar to certificate revocation lists (CRLs) in traditional PKIs.

Sneakernet bundles

Awala courier networks may optionally distribute a curated collection of broadcast parcels, to distribute information that may be generally relevant to Awala users in the region served. For privacy and safety reasons, private gateways would download the entire collection (or specific shards if we use sharding), to avoid disclosing to the courier what the user is interested in.

Such collections may include broadcasts from news organisations, humanitarian organisations, political dissidents, etc.

P2P network amongst Awala Internet gateways

It'd only be used to propagate messages. Messages will only be persisted for 5 minutes to help peers that get disconnected.

Internet gateways will identify themselves with their Vera ids, so that abusive peers can be blocked by domain name -- thus making it expensive to attack the network. Attackers mustn't be able to bypass this by creating subdomains.

We're likely to need sharding as popularity grows, although it'd be ideal to make the number of shards a function of throughput.

Changes to the existing protocol suite

Messaging Protocols

• Broadcast parcels could be unencrypted (CMS type "data").
• The Cargo Collection Authorization MUST include zero or more topic subscriptions. The resulting cargo will remain end-to-end encrypted, to prevent leaking subscription-related information to couriers.

Alternatives considered

• IPFS PubSub/Gossipsub. It looks overly complicated given the many different use cases they want to support.

See also

• Draft Service Message Multicast protocol #42 for the multicast counterpart.
• https://matrix.org/_matrix/media/r0/download/twitter.modular.im/981b258141aa0b197804127cd2f7d298757bad20