133 lines
5.5 KiB
Markdown
133 lines
5.5 KiB
Markdown
# Solid
|
|
|
|
### 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.
|
|
|
|
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.
|
|
|
|
### Networking/Message passing
|
|
|
|
[Linked Data Notifications](https://www.w3.org/TR/ldn/)
|
|
|
|
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)
|
|
|
|
Currently smart clients retrieve messages with pull/get, rather than server push.
|
|
|
|
### Data Storage/Message Persistance
|
|
|
|
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.
|
|
|
|
Users may self-host their pods (on their own server) or use a "Pod Provider".
|
|
|
|
Users may also switch pods easily without losing their data (such as their contacts and chat history.
|
|
|
|
### Moderation/Reputation
|
|
|
|
access control is currently thru ACLs, can plug in different methods; could possibly be swapped out if desired
|
|
|
|
an agent with a webid can have control or other levels of access to a resource
|
|
|
|
### 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
|
|
|
|
```
|
|
{
|
|
"@context": {
|
|
"@language": "en",
|
|
"sioc": "http://rdfs.org/sioc/ns#",
|
|
"foaf": "http://xmlns.com/foaf/0.1/"
|
|
},
|
|
"@id": "",
|
|
"@type": "sioc:Comment",
|
|
"sioc:reply_of": { "@id": "http://example.org/article" },
|
|
"sioc:created_at": {
|
|
"@type": "http://www.w3.org/2001/XMLSchema#dateTime",
|
|
"@value": "2015-12-23T16:44:21Z"
|
|
},
|
|
"sioc:content": "This is a great article!",
|
|
"sioc:has_creator": {
|
|
"@id": "http://example.org/profile",
|
|
"@type": "sioc:UserAccount",
|
|
"sioc:account_of": { "@id": "http://example.org/profile#alice" },
|
|
"sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },
|
|
"foaf:name": "Alice"
|
|
}
|
|
}
|
|
```
|