@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.
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
gemini://, https:// and only http:// (like in my own twtxt.txt) or construct something like like a webfinger id nick@domain (also used by mastodon etc.) from the domain and nick if there, else use domain as nick as well
https://youtu.be/7Xf-Lesrkuc
Can't help myself, but I have to include the Uranus song now. :-D https://www.youtube.com/watch?v=OSWszdSHkyE#t=7
Another thought: if clients can't agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.
A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there's a period when clients are doing different things.
(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don't know about other clients.)
tt rewrite in Go. So, I thought I use the shiny io/fs.FS. That's supposed to be a super cool new file system API. It allowed me to write tests more elegantly. I don't have to place actual test files on disk, but can keep everything nicely in RAM with testing/fstest.MapFS. That actually worked out great, I do like that.However,
os.DirFS("/") for production code is just a terrible solution. I noted that OS paths and io/fs.FS paths are fundamentally different. This new API does not allow leading slashes in the passed paths. This results in an error. So, I have to cut the leading slash off myself.Also, the whole thing is totally useless on Windows, because of the drives. Simply does not work at all. Well, honestly, I don't care the slightest bit about that operating system, but it would be nice if this concept were cross-platform.
I haven't tested it, but I'm pretty sure relative paths or
~ do also not work. I have to first build absolute paths myself. Unfortunately, there is no builtin helper to translate an OS path into a io/fs.FS path.Of course, others noted these shortcomings and surprising results, too: https://github.com/golang/go/issues/44279 There is no
OSFileSystem implementation that would simply allow the easy transition from all the classical os.* functionality to io/fs.FS. And they also do not wanna add something like that either. Sigh.I'm really wondering what they were thinking when introducing this. :-?
Even though, it's very silly, I'm gonna keep using it. At least for now. Tests have been written. I'm not keen on rewriting them. Sigh.