↳
In-reply-to
»
Yeah.. it is very similar to salty.im a smp is a relay queue for messages. You can self host one if you choose. They also have something called xftp for data storage and device state transfer. You can also self host one.
⤋ Read More
I think salty.im is simplest than simplex. But attempt to implement this i have problems than salty cli cant decrypt messages from another saltpack realization (and reverse) . Also simplex is more decentralized (like nostr?)
↳
In-reply-to
»
On the Subject of Feed Identities; I propose the following:
⤋ Read More
So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.
What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:
The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.
The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?
From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.
I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.
# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...
↳
In-reply-to
»
(#lrmnw3a) @lyse I believe also that
⤋ Read More
yarnd's parser basically ignores the lines too.
@prologic@twtxt.net if we want to pick a signature form. We can probably get the parser to respect it. I think keys.pub puts the signed content inside the saltpack encoding. PGP header/footer should be an easy parse.
↳
In-reply-to
»
Below a signed (https://keys.pub) message:
⤋ Read More
@prologic@twtxt.net
BEGIN SALTPACK ENCRYPTED MESSAGE. kiNJamlTJ29ZvW4 RHAOg9hm6h0OwKt iMGN9pY3oc5peJE UcRA8ysyQ7e8co9 shMfScCFgmQgU5Q 6w6XD2FT6szO1i1 N8qWqFRwJcHliqp hlaSvsTNhuwe1Fs KESywjL8ZvxNeyb ro0RVcRIip4Itpv NKvFZ822RoDR6pb hVvSqgubr3IanFT 6VAGQe2mYvErE7i G0O284HNvj0tcbC qzY0uB3ZFePu2fp l8nHOeEm9QLkH4Y PNKY2bXjqtblDGq 7pNiNHXtNJDjrpG nUoEXK9CaB6DGe7 oaF1P9sTz7fFrUo qwIgzw4Z1yqULQW 6dcFgsGwQEMc6bV mXuJHkrDWbfw35o 2Lpevp4PAVw884t 5Jf4cDLAe3QfRjG 4y6uwJg8BwIr2Lb 2pCX23ffwJ0yjGs Ptyzuaq2Alfl3QX AcMNGFzTNHjHfqY cvsoTrSMbyE3ssS A0k0zeRJQLoGOK4 DGkdltMXaQyXq9d zzbueCXCsIM1vYG vcy85vKuqM0ikoG caUNUuIVCc6FMs5 2JtadCtbVKyG8Wx Z4R672Fd71eDjCc lEtCdJlEAmEJePw ThkxVJutJt2R2Ce lKp9tEKmrx1jMWW V8hJNTaQGAfFDEB Unh8YasaV24NqAi GKSnstFWk3DYCxC lvws9js2jJ9OKeq 2mMgFmzEmCr99RW 2CrxZStPpB1iEDU d0Un7W7bnyo2KpV xqe8rCeHA6CUwVs 0XMmxPvU1Q0wp9A 0Jwxo5CY9QF5EJl yVwaXiVP2CKw2aH tqEE5yTp9OmpNF0 jFqgr8vHOjosPyL c3nke0S9QFjAxjt Dr6xwYpnASDr1l1 N96G3FB5iVYLFaz FkXGm7oQNTaDY8e OtHXQiXRhQY3PCi VIYYVhc9RExVnfX fvzgfgc5uSxUynD sPp4eq2rJXkX5. END SALTPACK ENCRYPTED MESSAGE.
Let’s see how resilient this is, or if it breaks.
↳
In-reply-to
»
Below a signed (https://keys.pub) message:
⤋ Read More
Nope, that’s broken. Trying again:
BEGIN SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkBUqOhj jswhPYkyZTEUu5X o7Okqh4fYjSmiKh Jadku1SjBPAheqm o0RDUnaewjKUqE9 I3ZAB3Hyzfo1oea X7NqyjDTqSV4a4c RJhc3Zd2V40AXTK w7GsM8nn1eMviW9 CySVLa7QfT41v6l 78u7bxB2ETWLklN K0tbB4PApao5URL 8gNObm. END SALTPACK SIGNED MESSAGE.
Below a signed (https://keys.pub) message:
BEGIN SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkBUqOhj jswhPYkyZTEUu5X o7Okqh4fYjSmiKh Jadku1SjBPAheqm o0RDUnaewjKUqE9 I3ZAB3Hyzfo1oea X7NqyjDTqSV4a4c RJhc3Zd2V40AXTK w7GsM8nn1eMviW9 CySVLa7QfT41v6l 78u7bxB2ETWLklN K0tbB4PApao5URL 8gNObm. END SALTPACK SIGNED MESSAGE.
@kas@enotty.dk, @kdave@kdave.github.io I don’t get it. How do i generate keys for #saltpack? Do i need #keybase to use it?
@kas@enotty.dk, @kdave@kdave.github.io I don’t get it. How do i generate keys for #saltpack? Do i need #keybase to use it?