Update 'MultiDevice Announcements POC'

emdee 2022-10-07 22:25:28 +02:00
parent 22b10c617d
commit 546df1dd05

@ -36,7 +36,7 @@ Some clients may let the user decide whether of not to accept a blob update when
## MultiDevice Announcements Blob ## MultiDevice Announcements Blob
So what is the blob of information that is pushed by DHT annoucements, or in the messages to the friends group? So what is the blob of information that is pushed??
It has these characteristics: It has these characteristics:
@ -83,7 +83,9 @@ Unknown for now is does the client have to send an add request to the new ToxID
The clients would manage this seemlessly to aggregate the ToxPks together under one Persona that is shown to the user. The library does most of this by accepting the update from the blob to update the table pointing from PersonaID to the new list of ToxPks (devices) with the first one being the active one. The clients would manage this seemlessly to aggregate the ToxPks together under one Persona that is shown to the user. The library does most of this by accepting the update from the blob to update the table pointing from PersonaID to the new list of ToxPks (devices) with the first one being the active one.
Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the firends. Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the friends.
Or you could push a blob as a file similar to how avatars work, if it got to big for a status message.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the universal group, or simply put the signing key and a a blob.gz.base64 in the status message. The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the universal group, or simply put the signing key and a a blob.gz.base64 in the status message.