devol
/
ecosistema-social-decentralizzato
mirror of https://gitlab.com/bluesky-community1/decentralized-ecosystem.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update peergos

This commit is contained in:
Jay Graber 2020-06-15 13:43:06 -07:00
parent 2bbaa6aad7
commit e3b0e21fff
1 changed files with 41 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
protocols/peergos.md
View File

@ -1,39 +1,61 @@
# Peergos # Peergos
Peergos is a peer-to-peer end-to-end encrypted storage, social and application protocol and platform. It is built on top of IPFS. More information is available in their [book](https://book.peergos.org) or their [source](https://github.com/peergos/peergos). Peergos is a p2p end-to-end encrypted storage and application protocol on top of IPFS. It is also a social application by the same name. It is designed to be independent of DNS and TLS certificate authorities, and to protect privacy through quantum resistant encryption.
It is designed to be independent of DNS and TLS certificate authorities and use strong quantum resistant encryption and design.
Peergos was [started in 2013](https://peergos.org/about) with the aim of a secure decentralized file storage and sharing network with a secure email replacement.
### Identity ### Identity
There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. Names are taken on a first come first served basis. Consensus is currently a single server, but long term this would make sense to put into a stripped down blockchain for more decentralization. Peergos users are identified by unique usernames linked to public keys. The uniqueness of usernames is ensured through a global append-only log for [public key to username](https://book.peergos.org/architecture/pki.html) mappings that is mirrored on every node in the Peergos system. Names are taken on a first come first served basis. Currently, a single server determines the canonical state of this log, and other nodes sync to it. Long-term considerations include decentralizing the name server through a blockchain architecture.
Login and key management: A peergos user's private keys are derived every time they log in using their username, password and a published salt. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. Users store their friends keys in their encrypted storage space in a TOFU keystore. Users can verify key of friends in person or over the phone using QR codes or fingerprints. Peergos allows [multi-device login](https://book.peergos.org/features/multi.html) through a password-based interface. A user's private keys are derived every time they log in using their username, password and a published salt. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. Users store their friend's keys in their encrypted storage space in a TOFU keystore. Users can verify their friend's keys out of band using QR codes or fingerprints.
This enables multiple device support, and no awkward key management UX. The user never needs to see a key or a hash. ### Network
### Data storage Each user must be registered to at least one Peergos server (A server can host any number of users and any server can choose to mirror data for any user). Peergos servers run an instance of IPFS, which handles networking and connection management.
Each user must have at least one peergos server (A server can host any number of users and any server can choose to mirror data for any user). The servers run an instance of IPFS. Data is content-addressed: stored in mappings from hash to data. During upload the client splits files into 5 MiB chunks which are each independently encrypted (along with encrypted metadata) and stored in a merkle-CHAMP (compressed hash array mapped prefix trie) in ipfs. Directories can't be distinguished from small files, nor are the sizes of files, or the number of files, or directory structure, or who has access to them visible to the server. ### Data
The user lists the IPFS node id of the server (hash of its public key). It synchronizes their writes and displays the latest root hashes. Data is always encrypted on the servers. The servers are in fact trustless - in that they don't have access to any sensitive information, and clients don't rely on them for authenticity or privacy. Furthermore, the servers don't trust IPFS, or the data store (which can be further removed, e.g. S3). Data is content-addressed: stored in mappings from hash to data. During upload the client splits files into 5 MiB chunks which are each independently encrypted (along with encrypted metadata) and stored in a [merkle-CHAMP](https://book.peergos.org/architecture/champ.html) (compressed hash array mapped prefix trie) in IPFS. Directories can't be distinguished from small files. Servers do not have visibility into the file sizes, the number of files, directory structure, or which users have access.
Peergos can handle arbitrarily large files, including random access, upload and download, even on under powered devices like mobile phones. This is largely due to the independently encrypting each 5 MiB section, as well as our novel "[zero IO](https://peergos.org/posts/fast-seeking)" seeking within a file. The user lists the IPFS node ID of the server (hash of its public key). It synchronizes their writes and displays the latest root hashes.
### Social ### Moderation & Reputation
Users can follow each other. Follow requests are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. Critically, the server never sees who is following who (even follow requests are blinded). You store your own social graph encrypted in your peergos space. ### Social & Discovery
### Privacy and Access Control Users can follow each other. [Follow requests](https://book.peergos.org/architecture/follow.html) are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. Critically, the server never sees who is following who (even follow requests are blinded). Users store their own social graph encrypted in their Peergos space.
All encryption happens on the client, which might be a native peergos client, or just a browser. The Peergos nodes (the servers) don't have access to any metadata. ### Privacy & Access Control
Access to files gained through social follows can be revoked by rotating cryptographic keys. Access is hierarchical, and stored in an encrypted structure call [cryptree](https://book.peergos.org/security/cryptree.html). All encryption happens on the client, which could be a native Peergos client or a browser. Data is always encrypted on the servers. Servers do not have access to metadata or sensitive information. Furthermore, the servers don't trust IPFS, or the data store (which can be further removed, e.g. S3).
Access is controlled through cryptographic capabilities. A read-only capability consists of the hash of the public key of the owner of the file, the writer of the file, a random label, and a symmetric encryption key: Access is controlled through cryptographic capabilities. A read-only capability consists of the hash of the file owner's public key, the hash of the writer's public key, a random label, and a symmetric encryption key. Access to files gained through social follows can be revoked by rotating cryptographic keys. Access is hierarchical, and stored in an encrypted structure called [cryptree](https://book.peergos.org/security/cryptree.html).
(owner hash, writer hash, 32 byte random label, 32 byte symmetric key)
A writable capability additionally includes the privat eky corresponding to the writer key, which is used to sign updates. To make a file or folder publically visible, a user can publish its capability. A user can also share secret links to files, like a google doc "share" link, which lets anyone who views it view the file. These [secret links](https://book.peergos.org/features/secret.html) don't expose the file to the server. The file is not transmitted unencrypted over the network, as the key to decrypt it is in the URL itself, and is interpreted locally in the browser.
A user can publish a capability of a file or folder they control which makes it publicly visible. A writable capability includes the private key corresponding to the writer key, which is used to sign updates.
A user can also share secret links to files, like a google doc "share" link, which lets anyone who views it view the file. These secret links still don't expose the file to the server. The file is not transmitted unencrypted over the network, as the key to decrypt it is in the URL itself, and is interpreted locally in the browser. ### User experience (if applies)
### Interoperability
### Scalability
Peergos can handle arbitrarily large files, including random access, upload and download, and on under-powered devices like mobile phones. This is largely due to the independent encryption of each 5 MiB section, as well as the "[zero IO](https://peergos.org/posts/fast-seeking)" seeking within a file.
### Metrics
### Governance & Business Models
Peergos was developed by the [core team](https://peergos.org/about) on a [self-funded](https://donorbox.org/peergos) volunteer basis for years. It has received grants from [Protocol Labs](https://peergos.org/posts/dev-update), the company that stewards IPFS.
### Implementations
Peergos is a private and access controlled layer on top of IPFS which can be used to build applications. Other than the Peergos reference implementation client which allows users to store and share private files, there are a few demo [applications](https://peergos.org/posts/applications), including a read-only viewer for PDF files, and an editor for text or code.
### Links
[Peergos](https://peergos.org/)
[Peergos book](https://book.peergos.org)
[Source code](https://github.com/peergos/peergos)