# Meeting people in ÐWeb

In the centralized web people meet each other in silos of centralized systems. They implicitly entrust the system to facilitate and govern exchange with strangers.

### Pros

- System provides spam filtering
- System ensures participants are individuals

> Meaning an entity that is not an ill-intended bot

- System ensures assigned unique identity to each participant
- System provides some means of moderation (block/mute specific individuals)

### Cons

- System is effectively a surveillance tool

> The best case scenario, is that it uses this as a means to filter spam. More often, this is monetization vector.

- System is a silo, enforcing all exchanges to occur with in it

- There is no real way to affect moderation, other than to block individual abusers, or rage-quit and leave all connections behind

### Participation rules

It is important to point out that in todays centralized systems all the trust lays in the server. It is also important to understand that the server defines and enforces participation rules.

In ÐWeb there is no server to set, or enforce, participation rules. Therefor, ensuring that participants are individuals with stake is fundamental to enabling exchange with strangers.

Most ÐWeb systems today do not provide a safe way to start an exchange between strangers. This often means that strangers may never see messages directed at them.

#### [SSB][]

Networks like [SSB][] embrace novel friend-to-friend approach to networking, enabling exchange & moderation by the community.

Whether this replaces the need for strangers to exchange information seems unclear.

#### [Holochain][]

[Holochain][] provides a way to encode rules of participation into an application's DNA. This provides a way to facilitate exchange & moderation at application level.

However, this requires protocol client to embed [VM](https://en.wikipedia.org/wiki/Virtual_machine) for executing rules, or possibly entrusting reputable node.

## Role of User Agent

It seems, regardless of technical details, there is always an **entrusted entity** that ensures participants are individuals, and establishes message exchange channel between them. It seems natural that in ÐWeb that would be a role for **User Agent**.

It also seem fit that **User Agent** would provide means to bridge centralized web with ÐWeb.

### Implementation details

> We will use the [dat][] protocol for illustration purposes, but it is as applicable to [ipfs][] via **ipns**.
>

In the [dat][] ecosystem, everyone can create their own stream of information by starting a new dat. We can think of it as stream with many channels (some could be encrypted), where authors publish information. In this system, applications are just tools for publishing messages into a stream channel, and viewing information from subscribed streams.

Critically, strangers have no means to getting a message across without being followed. To address this, strangers would need a way to introduce themself (request to be followed), but such requests need to be moderated on the terms set by individuals.

#### Identity

Individuals could use a dedicated dat, where they are its author, as an identity. Key role of identity is to provide proofs of being individual.

That would enable participants to set terms of introduction, by requiring certain proofs.

#### Introductions

In order to facilitate introductions, trusted entities that we will refer to as **introducers**, could run meeting rooms. These would be entries addressed **to** individuals, containing adddresses of streams **from** individuals attempting to introduce themself.

- An individual would announce accepting introductions through an entrusted introducer, by creating an entry with a name containing the address of the introducer identity, and a value of a **subscription key** + nonce encrypted with introducer's public key.
> The intent here is to establish a channel (an inbox), where introducer could privately publish introductions.

- **To** entry name will be a **subscibtion key** (described above) mapped to a list of introductions, where **introduction** is an addresse for the private stream of messages from individual making introduction towards individual accepting introduction. **itroduction** is encrypted with a public key of the identity accpting introduction.
> The intent here is to make introductions private. Identity receiving introduction can use private key to unveal the address of the identity introducing themself, while **introducer** can not.

This enables individuals to entrust friends, or other entity like **User Agent**, to facilitate private introductions on their own terms without revealing their exchange.

> If an entrusted entity fails to uphold terms, they can always choose other more trustworthy entity.
>

#### Terms

The primary vector to prevent spam, is to ensure that participants are individuals with proofs of stake. Allowing individuals to decide which is the right stake for strangers to get on their radar seems only fair.

#### Proof of Ownership

One way to enusure an identity belongs to an individual, would be to require proof of account ownership. This is inspired by [IndieAuth][], where individuals can prove to own a Github identity, Twitter, Facebook, or Domain Name.

User Agent could authenticate the user with a corresponding service, and on success, provide proof (token encoded with own private key) and store this in the identity dat.

This would enable individuals to accept introductions from strangers, that prove their ownership of certain accounts.

> **Note:** Proof of ownership still entrusts centralized silos, although it is going to be convinient to bridge with an existing systems.

#### Proof of Identity (POI)

Individuals could still prove to be an individual with stake, without dependence on centralized silos. This could be utilized via [Proof of Work][POW] - POW system similar to bitcoin.

> **Note**: Unlike bitcoin, POW would need to be performed just once per individual (and not per introduction), and without any competition.

In this system, a public key of an identity can be used as [POW][] base string. The individual could decide complexity / cost of a proof, and then either produce proof on own machine or pay for the service. The discovered solution can then be stored into a corresponding identity dat as proof.

> **Note:** In many ways this is very similar to using a Domain Name as an identity. A major difference that it incurs a one time cost only, and does not depend on a central authority.

This not only provides a fully decentralized way to prove an identity, but also has built-in cost element. This allows individuals to reflect cost into the terms of introduction.

> **Hypothesis:** If it costs $5 to create an identity, that can easily be reported and blocked by an authority, it's unlikely to become an effective spam delivery vector. Costs can be tuned to make spam prevention effective.
>

## Concerns:

### [Forward secrecy]

Document currently does not support forward secrecy in that all introductions end up under same **subscribtion address** and if that is compromised attaker would be able to check if specific individual performed an introduction. I imagine key rotation mechanism could be incorporated to make system more resilient e.g. individual accepting introductions could periodically generate new **subscribtion address**.

Maybe [Diffie–Hellman key exchange][] could be used to as an alternative to **subscribtion address**.

> I'd encourage someone with expertice in this space is to provide feedback.
>

### Similar project

- [uport](https://www.uport.me/)
- [jolocom](http://jolocom.io/)

[ssb]:https://www.scuttlebutt.nz/
[holochain]:http://holochain.org/
[dat]:http://datproject.org/
[ipfs]:http://ipfs.io/
[IndieAuth]:https://www.w3.org/TR/indieauth/
[POW]:https://en.wikipedia.org/wiki/Proof-of-work_system

[Forward secrecy]:https://en.wikipedia.org/wiki/Forward_secrecy
[Diffie–Hellman key exchange]:https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange