SolidOS / solid-ui

User Interface widgets and utilities for Solid
https://solidos.github.io/solid-ui/dist/solid-ui.js
MIT License
146 stars 39 forks source link

Chat thread with signed messages #546

Open bourgeoa opened 1 year ago

bourgeoa commented 1 year ago

Tasks :

bourgeoa commented 1 year ago

Ontology and keys

- 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

key discovery



### 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`.
melvincarvalho commented 1 year ago
: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

bourgeoa commented 4 months ago

@timbl @angelo-v @megoth Working chat with thread and signed messages. Tested with NSS. Needs following PRs

megoth commented 4 months ago

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.