Code of Conduct: https://github.com/solid/process/blob/master/code-of-conduct.md - Website: https://solidproject.org/ - Repos: https://github.com/solid/
@gibsonf1 Good to hear — so if your are Lisp people then you’ll like the turtle syntax for lists! So many people think in JSON arrays when it comes to syntax. But when it comes to the API rdflib has Array/List as a first class object, which is sane (compared to having first/rest ladders all over the place for devs to deal with).
$ node chat-notify.js list
Installing Rest Handler solid-rest-file-storage-1.0.0 using prefix file
Installing Rest Handler solid-rest-localStorage-1.0.0 using prefix ls
Log into solid
me https://timblbot.inrupt.net/profile/card#me
loaded <https://timblbot.inrupt.net/profile/card>
Preferences file: <https://timblbot.inrupt.net/settings/prefs.ttl>
statements: 6
Seems to basically work
Well done @jeff-zucker — thanks for filling that yawning gap!
When Solid apps start, they just store all the data they need to work in your pod. They don't store the data themselves at some computer run by the person who owns the app. So by default you control all the data in your Solid world. This is a massive improvement to your privacy.
@InfiniteStyles see the discussion on that topic in the forum : https://forum.solidproject.org/t/read-only-content-on-pod/998
TIL : Github, out of respect for the Black Lives Matter movement, has changed the default for the default branch of new projects from "master" to "main" in order not to use the "master/slave" analogy.
Is Solid using the DID standard for IDs?
@InfiniteStyles for non repudiation banks will have to keep data on their side. Tampering is easy to avoid (signature as explain in the post). Delete is another story. And keeping hash only on bank side is not enough. Because in case of fraud they have to proof with data and ensure data lineage...
Btw the question is the same with « consent ». Consent you give to org X on your pod data is not in your control only but also in control of the org x (for same reason - non repudiation and audit in case if gdpr litige) on that one i beleive decentrzlised ledger is the right answer - on top of solid)
Btw the question is the same with « consent ». Consent you give to org X on your pod data is not in your control only but also in control of the org x (for same reason - non repudiation and audit in case if gdpr litige) on that one i beleive decentrzlised ledger is the right answer - on top of solid)
@beaule
Consent you give to org X on your pod data is not in your control only but also in control of the org x (for same reason - non repudiation and audit in case if gdpr litige) on that one i beleive decentrzlised ledger is the right answer - on top of solid)
This means that the organization you share a part of your pod data with has a copy of your data, not control of your pod. Right? A decentralized ledger seems necessary for a DID?
Trying to understand how the Solid ID system differs from the DID system, or if they are possibly the same thing?
@InfiniteStyles i m not an deep expert and let solid people answer. Solid relies on webid so no need of decentralised ledger for that one. You trust the solid provider. But you can switch when you want. For consent its different i beleive because consent is not in full hand of the user. So we need a neutral place between user and org that use data to store that consent in an immutable way. Ledger can male sense for this (my opinion).
Coming back on bank data, the copy is not the way to go i beleive. Solid in my opinion should solve the duplication of data and single source of truth.
In ideal world, you should have certified bank data pod (managed by banks maybe?) where data are managed according to bank data rules (meaning that data can no be deleted... and this must be enforced by the pod provider that comply with these rules).... lots of work and reflexions to have 😉
Coming back on bank data, the copy is not the way to go i beleive. Solid in my opinion should solve the duplication of data and single source of truth.
In ideal world, you should have certified bank data pod (managed by banks maybe?) where data are managed according to bank data rules (meaning that data can no be deleted... and this must be enforced by the pod provider that comply with these rules).... lots of work and reflexions to have 😉
@InfiniteStyles (for context, several people in the DID community and w3c Working Group are also involved in the Solid community, so, there's definitely cross-pollination there). DIDs and WebIDs are essentially identical. They're both URLs (though DID URLs tend to go beyond the world wide web, and into other protocols such as ledgers etc). And when you resolve that URL, you get back machine-readable data (in linked data format).
The main difference between DIDs and WebIDs is - what is the resulting data allowed to contain? DID Documents are allowed to contain (at least in the core spec) only two things - cryptographic key material, and "service endpoints" (links to other related documents, basically).
WebID Profiles (how Solid uses them currently today) contain more types of data - key material, links to related documents, but also "user info" / social media profile type of data.
Here's an issue, for example, that proposes interop between DIDs and WebIDs in the Solid ecosystem - solid/identity-panel#1
(it also has a diagram that hopefully illustrates the difference between the two).
@InfiniteStyles as for your other comment, about whether DIDs require a decentralized ledger - so, the answer is no, but it totally makes sense that one would get that impression from looking at the DID conversations on the web, since so many of those focus on ledger-based DIDs.
so there's basically 4 categories of DID methods. 1) ephemeral/self-contained/peer-to-peer type of DIDs. such as the very simple did:key method, and the (considerably more complicated) did:peer method
2) blockchain/distributed ledger based methods (which can further be classified as: a) public permissionless (cryptocurrency based) ledgers like Bitcoin and Ethereum), b) purpose-build ledgers just for DIDs, which typically tend to be public permissioned (examples are Veres One and Hyperledger Indy/Sovrin), and c) Private blockchains (based on Hyperledger Fabric). 3) DHT (Distributed Hash Table) based methods like Blockstack and IPFS. and 4) did:web method (which basically uses web URLs and hosts did documents on websites) - this one is the most compatible with current Solid ecosystem, obviously.
Thank you @michielbdejong! It's been a real pleasure working with Solid Community these past two years and I hope to cross paths again with many of you in the field. Please do feel free to contact me, I'm on email@mitzilaszlo.org and would love to hear what you are up to.
