Open bourgeoa opened 1 year ago
key resources : actually uses a Class vocab (this is not a valid predicate)
# Actually
:me cert:PrivateKey "string" # in a resource READ only for the owner
:me cert:PublicKey "string"; # in an other resource Read only for everybody:msgId cert:proofValue proofString;
:msgId cert:proofValue proofString;
# Could be replaced by
:me cert:key keyString; # keystring is the private or publicKey
:msgId cert:proofValue proofString;
or
:me solid:secp256k1PrivateKey keyString;
:me solid:secp256k1PublicKey keyString;
:msgId solid:schnorrSignature proofString; # could replace proofValue
- keys discovery
This is actually in a fixed location (/profile/keys/privateKey.ttl and publicKey.ttl) in a pod storage.
- PodStorage is discovered using :
- first pim: storage from webID document with a priority rootWwebib in case of multiple pim:storage
- and if none parsing recursively the webID URI for pim:Storage link Headers
- Shall the container/resources location be recorded in webID document or in settings. The risk is misuse by user
publicKey could be located in the WebID document. Mis-use could be limited :
- with automatic rebuild out of the privateKey (this is already implemented if publicKey is invalid/undefined)
- and also if the publicKey is stored with the message
### Signature issues
- chat members (Append Only)
- `automatic` : shall a chat member sign, unsigned messages whenever this member is logged in ? This could be limited to displayed messages
- owner/managers functions (they are able to add Write authorization)
- `on demand to owner` : remove deleted messages ?
Even not displayed, the deleted messages are readable by going to the tree structure
Deleting messages definitely make them not restorable, we may encode/decode them with an owner/managers symmetric key
- `on demand to owner` : changing privateKey, this returns invalid signature
Owner can remove invalid chat members signature and allow automatic rebuild signature when a chat user relogs
### How to consider WebID being deleted ?
Actually all related messages will have an invalid signature
- a fallback with the public key stored in each message is possible (the key is a rather short ans clean string,
- or globally at the chat channel level in index.ttl- but with authorization issues (ReadAppend) ?
### Chat channel issues
Global options and individual chat options are available in the same resource index.ttl
The chat channel authorization, apply by default :
- `ReadWriteControl` by creator. May be limited to `ReadWrite`. In which case an Owner can edit the ACL
- `ReadAppend` by all authenticated members.
- `Read` by everybody
This means that `individual options can be set but not modified`.
:me solid:pubkey keyString # keystring is 64 char hex string
:me solid:privkey keyString # keystring is 64 char hex string
Or some variant of this
In general, lower case hex strings are most common in implementations
You dont even need to wait for the terms to get upstream because the labels will display nicely enough, and the functionality will be in the library
@timbl @angelo-v @megoth Working chat with thread and signed messages. Tested with NSS. Needs following PRs
Hey, I see that I'm tagged here. Just FYI I don't have any excess energy to spend on rdflib.js or SolidOS at the moment =/ Just so there's no expectation that I'll be able to do this work.
Tasks :
[ ] manage pod keys
solid
ontology shall replacecert
ontology that do not cover privateKey : creation of 2 new terms privateKey and publicKeyparentSettings/profile/keys/publicKey.ttl
triple => :me solid:publicKey keyString # keystring is 64 char hex stringparentSettings/settings/keys/privateKey.ttl
/settings/ is discovered from WebID preference file triple => :me solid:privateKey keyString # keystring is 64 char hex string[x] chat logic
[x] chat channel
[x] sign and verify object message. Cover Threads
[x] UI
[ ] tests
[ ] push key management in solid-logic ?
[ ] documentation