@prologic@twtxt.net hey, what’s the one liner to sign using an SSH key with salty?
@bender@twtxt.net Ahh yeah sorry about that 🤣 You were getting confused between salty.im and salty. The later of which salty.im actually uses and formed the basis of everything else. It’s a simple robust library and command-line tools with good test coverage. The lowest building block 😅
I think I know what I did wrong. LOL. I used the wrong repository. Going for go install go.mills.io/salty/cmd/salty@latest instead. Duh!
@prologic@twtxt.net So, I did 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?
@movq@www.uninformativ.de That bad eh? 😅
It’s one of those days.
For example:
$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world
@bender@twtxt.net Yes of course it can 😅 Sorry I missed your question on IRC 😢
@prologic@twtxt.net can salty verify ed25519 signed messages? I asked on IRC, but never got a reply (or I missed it).
@jmjl@tilde.green howdy! Sorry for mistaken you with https://blog.nfld.uk/ (jlj), but glad to connect. Cheers!
@mckinley@twtxt.net To answer some of your questions:
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.
@bender@twtxt.net Holy shit that pod is still alive?! 🤔
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
@sorenpeter@darch.dk WebFinger requires additional setup that whilsts helps to solve the “identity” problem in an “abstract” way, that extra infra that needs to be setup a) isn’t trivial and b) hard to support on “shared hosting”.
Sharing hosting is also the reason why you can’t just use part of a URL really.
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
how little data is needed for generating the hashes? Instead of the full URL, can we makedo with just the domain (example.net) so we avoid the conflicts with 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
Wow, a blast from the past. Look at that Yarn version!
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
@movq@www.uninformativ.de Peobably not and I wouldn’t expect them to either 😅
But in all seriousness I’ve only ever wanted to improve Twtxt without sacrificing its simplicity too much.
@movq@www.uninformativ.de Sorry haha I didn’t mean for it to sound like that 🤣
@mckinley@twtxt.net Hmmm? Care to elaborate? 🤣
@falsifian@www.falsifian.org tag:twtxt.net,2024-09-08:SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs? :)
Key rotation
Key rotation is useful for security reasons, but I don’t think it’s necessary here because it’s only used for verifying one’s identity. It’s no different (to me) than Nostr or a cryptocurrency. You change your key, you change your identity.
It makes maintaining a feed more complicated.
This is an additional step that you’d have to perform, but I definitely wouldn’t want to require it for compatibility reasons. I don’t see it as any more complicated than computing twt hashes for each post, which already requires you to have a non-trivial client application.
Instead, maybe…allow old urls to be rotated out?
That could absolutely work and might be a better solution than signatures.
HTTPS is supposed to do [verification] anyway.
TLS provides verification that nobody is tampering with or snooping on your connection to a server. It doesn’t, for example, verify that a file downloaded from server A is from the same entity as the one from server B.
feed locations [being] URLs gives some flexibility
It does give flexibility, but perhaps we should have made them URIs instead for even more flexibility. Then, you could use a tag URI, urn:uuid:*, or a regular old URL if you wanted to. The spec seems to indicate that the url tag should be a working URL that clients can use to find a copy of the feed, optionally at multiple locations. I’m not very familiar with IP{F,N}S but if it ensures you own an identifier forever and that identifier points to a current copy of your feed, it could be a great way to fix it on an individual basis without breaking any specs :)
My first thought when reading this was to go to my typical response and suggest we use Nostr instead of introducing cryptography to Twtxt. The more I thought about it, however, the more it made sense.
There are a couple of elephants in the room that we ought to talk about.
🧮 USERS:1 FEEDS:2 TWTS:1087 ARCHIVED:78676 CACHE:2491 FOLLOWERS:17 FOLLOWING:14
@lyse@lyse.isobeef.org let’s do Drops of Jupiter too! (hopefully my markdown foo works, if not I am editing and breaking replies! 😅)
@lyse@lyse.isobeef.org oooooh! That one looks lovely too! Let me know when there is something to alpha/beta test. I am volunteering! 😊
@movq@www.uninformativ.de Yep, that’s very nice music. :-)
Can’t help myself, but I have to include the Uranus song now. :-D https://www.youtube.com/watch?v=OSWszdSHkyE#t=7
@lyse@lyse.isobeef.org This looks like a nice way to do it.
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.)
Thank you, @bender@twtxt.net! No, the rendering is based on https://github.com/rivo/tview.
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.
@lyse@lyse.isobeef.org I just wanted to state that this is excellent news! Are you going to use some BubbleTea? 🙈
It’s been a little over 14 years since Isis broke up and I have yet to find a band as good as them. Not a single song that disappoints (at least since the Oceanic album). Glad I could see them live a couple of times. // Isis - Grey Divide // https://www.youtube.com/watch?v=eI2-8I3j4Vg #NowPlaying
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.
https://github.com/spf13/afero looks better, but has a gazillion dependencies. So that’s out.
I’m finally continuing with my 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.
Great, now I fell into a rabbit hole of “old” music. 😂 https://www.youtube.com/watch?v=PGNiXGX2nLU
@prologic@twtxt.net Come on, that’s a little condescending, isn’t it? 😅
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
For the record, out of the 89 feeds that I follow, only a single one has more than one # url = field:
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen@gemini.ctrl-c.club is aware that the order of those fields matter. 🤔
@movq@www.uninformativ.de True 👌
@movq@www.uninformativ.de Tbey all hate me for stomping on their precious dear twtxt 🤣
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
@lyse@lyse.isobeef.org Hmmm interesting idea 🤔
@prologic@twtxt.net Oh, wait, there’s already another thread about it. 😅
url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
On second thought, the same rule with the last physically encountered URL when starting parsing from the top applies to prepend-style feeds as well. Much simpler and cleaner this way. Should also fit prepend-style feeds better I reckon.
@falsifian@www.falsifian.org In my opinion it was a mistake that we defined the first url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:
# url = https://example.com/alias/txtxt.txt
# url = https://example.com/initial/twtxt.txt
<message 1 uses the initial URL>
<message 2 uses the initial URL, too>
# url = https://example.com/new/twtxt.txt
<message 3 uses the new URL>
# url = https://example.com/brand-new/twtxt.txt
<message 4 uses the brand new URL>
In theory, the same could be done for prepend-style feeds. They do exist, I’ve come around them. The parser would just have to calculate the hashes afterwards and not immediately.
Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt 😅
@prologic@twtxt.net @bender@twtxt.net That’s exactly the case here with us as well. Maybe not 100% applicable to yarnd, but all other clients that only fetch from their user-controlled subscription list.
@movq@www.uninformativ.de @prologic@twtxt.net Oh yeah, we have to take our time with that and craft it very carefully.
My theory about the descent of the original twtxt universe is that a) people just move on to other things and b) it was just not practical enough.
Nicely put, @movq@www.uninformativ.de! Exactly, reminding people to subscribe etc. is dodgy. To me it feels they think their audience is dumb (and they might be right, I don’t know). Super annoying.
@aelaraji@aelaraji.com Just move to Mars to get an extra hour a day: https://spaceplace.nasa.gov/days/en/ If that’s not enough, Mercury should have you covered for sure.
@prologic@twtxt.net No, it’s all just speculation and I don’t like spreading rumors. 😅 It would be more interesting to hear from the twtxt folks themselves why they stopped working on the original twtxt.
the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
@falsifian@www.falsifian.org If the timestamp included a nanosecond part (which is not a valid twtxt feed at the moment, because it mandates RFC3339 timestamps and those only permit one subsecond digit), this could solve the editing problem with little effort. 🤔
Btw, @prologic@twtxt.net, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.