jenny -D otherwise, it misses things up if I add that snippet of text to links in my .config/jenny/follow file 😅 Anyway, it was a nice try.
jenny -D otherwise, it misses things up if I add that snippet of text to links in my .config/jenny/follow file 😅 Anyway, it was a nice try.
jenny -D otherwise, it misses things up if I add that snippet of text to links in my .config/jenny/follow file 😅 Anyway, it was a nice try.
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: ...
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: ...
A morir al palo. ⌘ Read more****
/https://duque-terron.cat/media/photos/IMG_1837.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
URI itself instead of relaying on the USER Agent 😂. I've copied my current feed over to my (to be) Gemlog for testing. And if I do a jenny -D "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" and this happens:A) As a follower, I get the feed as usual.
B) As the feed owner, I get this in logs:
> hostname:1965 - "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" 20 "text/plain;lang=en-US"
You could do the same for Gopher feeds but only if you want to announce yourself by throwing in an error in their logs, then you'll need a second request to fetch the feed.
jenny -D "gopher://gopher.aelaraji.com/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt" gave me this :> gopher.aelaraji.com:70 - [09/Sep/2024:22:08:54 +0000] "GET 0/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt HTTP/1.0" 404 0 "" "Unknown gopher client"
NB: the
follower=... string won't appear in gopher logs after a ? but if I replace it with a + or a & and it works. There will be a missing / after the https:. Probably a client thing.
URI itself instead of relaying on the USER Agent 😂. I've copied my current feed over to my (to be) Gemlog for testing. And if I do a jenny -D "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" and this happens:A) As a follower, I get the feed as usual.
B) As the feed owner, I get this in logs:
> hostname:1965 - "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" 20 "text/plain;lang=en-US"
You could do the same for Gopher feeds but only if you want to announce yourself by throwing in an error in their logs, then you'll need a second request to fetch the feed.
jenny -D "gopher://gopher.aelaraji.com/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt" gave me this :> gopher.aelaraji.com:70 - [09/Sep/2024:22:08:54 +0000] "GET 0/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt HTTP/1.0" 404 0 "" "Unknown gopher client"
NB: the
follower=... string won't appear in gopher logs after a ? but if I replace it with a + or a & and it works. There will be a missing / after the https:. Probably a client thing.
URI itself instead of relaying on the USER Agent 😂. I've copied my current feed over to my (to be) Gemlog for testing. And if I do a jenny -D "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" and this happens:A) As a follower, I get the feed as usual.
B) As the feed owner, I get this in logs:
> hostname:1965 - "gemini://gem.aelaraji.com/twtxt.txt?follower=aelaraji@https://aelaraji.com/twtxt.txt" 20 "text/plain;lang=en-US"
You could do the same for Gopher feeds but only if you want to announce yourself by throwing in an error in their logs, then you'll need a second request to fetch the feed.
jenny -D "gopher://gopher.aelaraji.com/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt" gave me this :> gopher.aelaraji.com:70 - \n "GET 0/twtxt.txt&follower=aelaraji@https:/aelaraji.com/twtxt.txt HTTP/1.0" 404 0 "" "Unknown gopher client"
NB: the
follower=... string won't appear in gopher logs after a ? but if I replace it with a + or a & and it works. There will be a missing / after the https:. Probably a client thing.
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
I could do that again in my client, but you're right, it's a different story for jenny. If I'm not mistaken,
In-Reply-To could contain several hashes, but the Message-ID header is the issue.By increasing the hash length for a potential future change, clients could tell, which algorithm to use.
Maybe we could define a magic timestamp in the future that marks the cutoff point. Use the current implementation for messages authored before that magic date or the new algorithm for all messages after that.
But eventually, all clients have to be updated. There's no way around that, I believe. Simplicity is key and my magic time already adds complexity. :-/
> if not I am editing and breaking replies!
Bwahahahaaa! :'-D
It's like that for months. :-( And tomorrow I even gotta go into the office for some two day meeting, but I only attend a single day. On the positive side, I'm gonna see some workmates that I haven't ever met in the real world or for a very long time.
ssh and ssh-keygen utilities. No reason really.
ssh and ssh-keygen utilities. No reason really.
$ echo 'hello world' | ./salty -i ./test_ed25519 --ssh-key --sign
$ echo 'hello world' | ./salty -i ./test_ed25519 --ssh-key --sign
salty, and salty-keygen? Why not both into one?
salty?
go install go.mills.io/salty/cmd/salty@latest instead. Duh!
go install go.salty.im/saltyim/cmd/salty-chat@latest, moved salty-chat to my bin as salty, and that one liner isn't working. What am I doing wrong?
#running
#running
#running
Good workout keeping it aerobic for the most part.
#running
Good workout keeping it aerobic for the most part.
#running
Good workout keeping it aerobic for the most part.
#running
$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world
$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world
salty verify ed25519 signed messages? I asked on IRC, but never got a reply (or I missed it).
> Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.
We already have this. Ed25519 libraries exist for all major languages. Aside from using
ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I'm sure there are other command-line tools that _could_ be used too.> If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.
Yes. This would happen, so we'd have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.
> Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.
We already have this. Ed25519 libraries exist for all major languages. Aside from using
ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I'm sure there are other command-line tools that _could_ be used too.> If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.
Yes. This would happen, so we'd have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.
Sharing hosting is also the reason why you can't just use part of a URL really.
Sharing hosting is also the reason why you can't just use part of a URL really.