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

Merge branch 'solid' into 'master' 

Finish Solid

See merge request arnoldjun/bluesky!73
This commit is contained in:
Jay Graber 2020-06-16 00:05:47 +00:00
parent 90ff069dcf 97add6c634
commit d5be0d17f1
1 changed files with 60 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

150
protocols/solid.md
View File

@ -1,110 +1,38 @@
# Solid
Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. It relies as much as possible on existing W3C standards and protocols, tying them together into a common framework.
The main concept behind Solid is that users store their personal data in a "pod" (personal online data store), and applications request access to it, rather than storing user data and accounts on an application server.
### Identity
Solid uses a [Internationalised Resource Identifier (IRI)](https://tools.ietf.org/html/rfc3987) as a WebID, requires an IdentityProvider; can be multiple Identity Providers.
Solid uses WebID URIs as universal usernames. The WebID URI's primary function is to point to the location of a public WebID Profile document.
The rights on a Pod are attached to WebIDs. WebIDs may refer to a person, a family or an organization. Instead of creating an account on each app, the app finds your WebID.
Example WebIDs: `https://alice.databox.com/profile/card#me` or `http://somepersonalsite.com/#webid`
### Networking/Message passing
A WebID is a globally unique, decentralized identifier. It enables cross-service federated sign-in, and does not tie a user's identity to a server. A WebID Profile Document is in Linked Data format, and contains identity information such as a username, profile image, preferences, and public key certificates.
[Linked Data Notifications](https://www.w3.org/TR/ldn/)
Solid requires cross-domain, de-centralized authentication mechanisms not tied to any particular identity provider or certificate authority, so it uses the WebID-TLS protocol instead of passwords. Instead of creating an account with a username and password for each service, a user selects a security certificate for the site from a popup. The server matches the private key stored by the user's browser with the public key stored in that user's WebID Profile Document to authenticate them.
Solid allows inboxes for any resource, ie actors or articles
Example: [annotations related to a particular article](https://linkedresearch.org/annotation/csarven.ca/%23i/87bc9a28-9f94-4b1b-a4b9-503899795f6e)
Username and password authentication mechanisms are an active area of research. Solid recommends that servers implement secondary account recovery mechanisms, such as email recovery, in case browser certificates are lost.
Currently smart clients retrieve messages with pull/get, rather than server push.
There is some discussion of [using DIDs in addition to WebIDs](https://github.com/solid/identity-panel/issues/1).
### Data Storage/Message Persistance
### Networking
Pod is a data storage space. All a user's data is stored here. Applications read and write data into the Pod depending on the authorisations granted by the user or users associated to that Pod. A person may have multiple pods, for example for work and for home. Data may be replicated across pods.
Solid allows inboxes for any resources, such as actors or articles. An example of an inbox for [annotations related to a particular article](https://linkedresearch.org/annotation/csarven.ca/%23i/87bc9a28-9f94-4b1b-a4b9-503899795f6e).
Users may self-host their pods (on their own server) or use a "Pod Provider".
Solid provides a [HTTPS REST API](https://github.com/solid/solid-spec/blob/master/api-rest.md) and a [Websockets API](https://github.com/solid/solid-spec/blob/master/api-websockets.md) for a PubSub mechanism. Smart clients currently retrieve messages with pull/get, rather than through server push.
Users may also switch pods easily without losing their data (such as their contacts and chat history.
Nofitications use the [Linked Data Notifications](https://www.w3.org/TR/ldn/) standard.
### Moderation/Reputation
### Data
access control is currently thru ACLs, can plug in different methods; could possibly be swapped out if desired
A data storage space is called a "pod" (personal online data store). All a user's data is stored in their pod. Users may self-host their pods (on their own server) or use a "pod Provider", a federated pod server. Applications read and write data into the pod depending on the authorizations granted by the users associated with that pod. A person may have multiple pods, for example for work and for home. Data may be replicated across pods. A key concept of the pod is that users may switch Pods easily without losing their data (such as their contacts and chat history).
an agent with a webid can have control or other levels of access to a resource
Solid [strongly encourages](https://github.com/solid/solid-spec#content-representation) the use of RDF-based Linked Data (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc) for interoperability with the ecosystem. The Solid [content representation spec](https://github.com/solid/solid-spec/blob/master/content-representation.md) encourages consistent naming conventions.
### Social/Discovery
WebID allows user addressing across all Solid-conforming apps
Resources (including WebID's -they have uris eg. https://csarven.ca/#i ) are self-describing. They are hosted on pods and have HTTP endpoints. With permissions, normal spidering is possible (from article, you will find author, etc)
There does not seem to be a Solid-based social network as of this writing, some discussion about creating one. Instead, Solid aims to create tools that enable building of decentralized social applications.
Any app that can parse the format can read the inbox, and could send responses.
### Privacy and Access Control
The owner of the pod controls access to who is authorized to read or write data. However if the user revokes access of an app to their data, the app can't further read or update the user's data, but they would still have the data that the user sent out prior to the revocation.
Data is always encrypted when in transition between an app and your pod. Note that pod providers don't necessarily have to encrypt the data on your pod.
### Monetization
Pod providers may or may not charge for hosting a pod. This will be determined by the market. They are hoping several business models emerge, some where the user pays for storage, and some funded by advertising for instance, like on the current Web platforms. Not clear which models are currently in use.
### User experience (if applies)
The Solid ecosystem includes apps built to use solid data pods.
Example apps:
[dokieli](https://dokie.li/) for publishing articles/posts
[exhaustive list of apps built on Solid](https://solidproject.org/use-solid/apps)
### Interop with other systems
Solid doesn't have its own sense of messages per se, but a Solid pod could be used for example in the implementation of an ActivityPub server.
The minimum requirement to be 'doing Solid' appears to be the use of JSON-LD (linked data) - discussion of [a subset of JSON-LD](https://stephank.nl/p/2018-10-20-a-proposal-for-standardising-a-subset-of-json-ld.html)
For example, dokieli (a solid app) is able to send notifications to ActivityPub
Some work on ActivityPub that is
[discussion of links between ActivityPub and Solid](https://socialhub.activitypub.rocks/t/which-links-between-activitypub-and-solid-project/529/8) - there is work to close the gap between the specs.
Compatible with existing web; WebAccessControl/ACLs etc are described in RDF
Some efforts are being made to make WebIDs compatible with DIDs
[Linked Data Notifications](https://www.w3.org/TR/ldn/)
Web Access Control
### Scalability
### Metrics
### Implementations
[Solid Apps](https://solidproject.org/use-solid/apps)
### Compare/contrast
Generally:
ActivityPub - smart server
Solid - smart client
### Links
- [Solid specification development](https://github.com/solid/specification)
- [Solid Ecosystem Editors Draft] https://solid.github.io/specification/)
- [Solid Chat] https://gitter.im/solid/specification)
- [Solid Community Group Meetings](https://www.w3.org/community/solid/wiki/Meetings)
[LDN Test Reports and Summary](https://linkedresearch.org/ldn/tests/summary)
[Linked Research on the Decentralised Web](https://csarven.ca/linked-research-decentralised-web#decentralised-linked-research-application)
[A Demonstration of the Solid Platform for Social Web Applications](http://crosscloud.org/2016/www-mansour-pdf.pdf)
(contributions also from Rahul Kothari and Sarven Capadisli)
### Payload example
An example payload:
```
{
@ -130,3 +58,45 @@ Solid - smart client
}
}
```
### Social & Discovery
Solid aims to create tools that enable the building of interoperable decentralized social applications. WebIDs allows user addressing across all Solid-conforming apps. Resources (including WebIDs) are self-describing, hosted on pods, and have HTTP endpoints with standard naming conventions to make discovery easier. Any app that can parse the format can read the inbox and send responses.
### Privacy & Access Control
A user's data is stored on their pod, which applications request access to. A user grants access to their data by selecting a security certificate to use with an application. If the user revokes access of an app to their data, the app will no longer be able to read or update the user's data, but would still have access to the data that the user sent out prior to the revocation.
Data is always encrypted when in transition between an app and a pod. Pod providers can encrypt data at rest on a pod, but are not required to.
Solid uses the [Web Access Control Spec](http://solid.github.io/web-access-control-spec/) for management of access control lists.
### Interoperability
Solid provides [specs and recommendations](https://github.com/solid/solid-spec#social-web-app-protocols) for interoperability between Solid ecosystem social applications. There are weekly meetings for the [Solid Data Interoperability Panel](https://github.com/solid/data-interoperability-panel) to discuss data interoperability across applications.
Solid is potentially compatible with federated social applications. For example, a Solid pod could be used in the implementation of an ActivityPub server. The minimum requirement to be conformant with the Solid protocol is the use of JSON-LD, which ActivityPub uses. Dokieli (a solid app) is able to send notifications to ActivityPub. A [discussion of the links between ActivityPub and Solid](https://socialhub.activitypub.rocks/t/which-links-between-activitypub-and-solid-project/529/8) highlights similarities, although work is required to close the gap between the specs.
### Governance & Business Models
Pod providers can choose whether to charge for hosting a pod. Possible business models include charging users for storage or advertising through applications.
[Inrupt](https://inrupt.com/faq) is a company committed to the development of Solid. It plans to monetize through consulting and pod hosting fees.
### Implementations & Applications
A list of [Solid Apps](https://solidproject.org/use-solid/apps). Apps built to use Solid data pods are considered part of the Solid ecosystem.
Solid does not have many widely used social applications yet, although there has been research such as [A Demonstration of the Solid Platform for Social Web Applications](http://crosscloud.org/2016/www-mansour-pdf.pdf).
An example application is:
- [dokieli](https://dokie.li/) for publishing articles and posts
### Links
- [Solid](https://solid.mit.edu/)
- [Solid spec](https://github.com/solid/solid-spec)
- [Solid repo](https://github.com/solid/solid)
- [Solid paper](http://emansour.com/research/lusail/solid_protocols.pdf)
- [Solid Community Group Meetings](https://www.w3.org/community/solid/wiki/Meetings)