94 lines
2.9 KiB
Markdown
94 lines
2.9 KiB
Markdown
### Key problems and existing approaches
|
|
|
|
See links in [overview.md](overview.md) for some mighty attempts at comprehensive lists of dweb protocols and projects.
|
|
|
|
The purpose of this document is to try to analyze how some of the existing dweb projects attack certain key problems:
|
|
|
|
* discovery of users and content
|
|
* interoperable messaging
|
|
* message queueing and persistence
|
|
* reputation
|
|
* identity and pseudonymity
|
|
* metadata and ownership
|
|
* economy of services
|
|
* scalability
|
|
* testing and metrics
|
|
|
|
Fundamental user stories being addressed here: I want to...send a message to a person I know, and I don't know what system they use for messaging; find a topic or person by keyword search; find reliable and credible information or resources on a topic; know the ownership/conditions around resources I find; have a way to pay for all the services without privacy intrusions; have a fast and stable experience at global scale; and have some way to evaluate all of the above on different systems.
|
|
|
|
### Discovery
|
|
|
|
* gossip mesh systems
|
|
|
|
* indexing and follow-bots
|
|
|
|
_how does one discover users and topics within each ecosystem_
|
|
IRIS - WoT mapping of human readable names to identity attributes - https://github.com/irislib/iris
|
|
|
|
### Messaging between systems
|
|
|
|
*What does a message from a user to another user look like on the wire?*
|
|
_(how similar are the schemas? can there be a universal schema with namespacing?)_
|
|
|
|
* Matrix - https://matrix.org/docs/spec/
|
|
(proposal for related events - https://github.com/matrix-org/matrix-doc/blob/matthew/msc1849/proposals/1849-aggregations.md)
|
|
Matrix messages are sent to rooms, which users are subscribed to. to message a user you first invite them to a room
|
|
```
|
|
PUT /_matrix/client/r0/rooms/%21636q39766251%3Aexample.com/send/m.room.message/35 HTTP/1.1
|
|
Content-Type: application/json
|
|
|
|
{
|
|
"msgtype": "m.text",
|
|
"body": "hello"
|
|
}
|
|
```
|
|
|
|
* ActivityPub - https://www.w3.org/TR/activitypub/
|
|
POST to the user's server's outbox endpoint
|
|
```{"@context": "https://www.w3.org/ns/activitystreams",
|
|
"type": "Note",
|
|
"to": ["https://chatty.example/ben/"],
|
|
"attributedTo": "https://social.example/alyssa/",
|
|
"content": "Say, did you finish reading that book I lent you?"}
|
|
```
|
|
|
|
### Message queueing and persistence
|
|
|
|
* Matrix - peered storage, replicated JSON between nodes
|
|
|
|
* GUN - graph db
|
|
|
|
* Mastodon - federated servers
|
|
|
|
### General decentralized storage
|
|
|
|
* IPFS - immutable, content-hash addressed
|
|
|
|
* DAT
|
|
|
|
* mutable systems using CRDTs
|
|
|
|
Example: GUN stores hacker noon annotations on user local storage - https://www.coindesk.com/hacker-noon-is-storing-content-on-a-blockchain-after-ditching-medium
|
|
|
|
|
|
### Reputation/credibility
|
|
|
|
* IRIS
|
|
|
|
### Identity
|
|
|
|
### Metadata and ownership
|
|
|
|
* Ceramic
|
|
|
|
### Economy of services
|
|
|
|
### Scalability
|
|
|
|
* AXE (reduce unneeded connections)
|
|
https://gun.eco/docs/AXE
|
|
|
|
### Testing and Metrics
|
|
|
|
* PANIC - https://github.com/gundb/panic-server
|
|
|