@slashdot@feeds.twtxt.net i’ll get fucked! The US patent office should ban this immediately.
@xuu True 😅 I guess it comes down to our risk appetite and the attack vectors we’re trying to solve for 🤔
@bender@twtxt.net yes I agree.
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:
@bender@twtxt.net there is a certain simplicity to that. 😅
@xuu it’s not really strictly required if we’re just talking about identity though right? If we’re talking about encryption then yes I agree rotate and keys becomes very important if you want to have attributes like perfect forward secrecy.
@xuu that could work too, but that requires a random value, a set of keys and signature verification of the value, which I don’t really have a problem with.
@xuu yes I’m less concerned about solving the integrity part of the problem of whether we can trust that the content of a feed is actually written by certain author, however, that’s not to say that we shouldn’t think about also leveraging keys to be able to do that maybe it’s an optional feature?
What were the recommended mitigations?
IMO we just have to fix the identity problem and figure out how to detect or support edits.
@sorenpeter@darch.dk No, this is what I want to avoid. For many reasons I stated before, content addressing or hashing is far better here for threading in a decentralized way.
@lyse@lyse.isobeef.org I personally think that we just go with a magic timestamp approach. It’s simpler and easier to implement across the major clients that are still actively developed.
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.
@movq@www.uninformativ.de if you do win the lottery, don’t forget to include us so we can all join in and share the things that we like to tinker with instead of this whole rat race. 🤣
@bender@twtxt.net Big photo capability upgrade?
# follow_notify = gemini://foo/bar
to your feed’s metadata, so that clients who follow you can ping that URL every now and then? How would you even notice that, do you regularly read your gemini logs? 🤔
@aelaraji@aelaraji.com Nice hack! 👌
@bender@twtxt.net I doubt I’ll be able to watch it live 🤣 But by all means, please Yarns all the goodies 😅
@bender@twtxt.net Kind of mirrored the ssh
and ssh-keygen
utilities. No reason really.
@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 😅
@movq@www.uninformativ.de That bad eh? 😅
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 😢
@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:
@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? 🤣
@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 🤔
On the Subject of Feed Identities; I propose the following:
- Generate a Private/Public ED25519 key pair
- Use this key pair to sign your Twtxt feed
- Use it as your feed’s identity in place of
# url =
as# key = ...
For example:
$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt
And your feed would looke like:
# nick = prologic
# key = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig = twtxt.txt.sig
# prev = j6bmlgq twtxt.txt/1
# avatar = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" 🇦🇺👨💻👨🦯🏹♔ 🏓⚯ 👨👩👧👧🛥 -- James Mills (operator of twtxt.net / creator of Yarn.social 🧶)
2024-06-14T18:22:17Z (#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt> Hehe thanks! 😅 Still gotta sort out some other bugs, but that's tomorrows job 🤞
...
Twt Hash extension would change of course to use a feed’s ED25519 public key fingerprint.
@aelaraji@aelaraji.com My work has this thing called “compressed work”, where you can buy extra time off (as much as 4 additional weeks) per year. It comes out of your pay though, so it’s not exactly a 4-day work week but it could be useful, just haven’t tired it yet as I’m not entirely sure how it’ll affect my net pay
@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.
My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌
Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt
seems to do or using the # url =
metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:
Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.
See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu _) that 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.
@aelaraji@aelaraji.com Join the club! 🤣 How about more days in a weekend?! 😱 Bringon #FourDayWorkWeek !!! 🤣
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 😅
@bender@twtxt.net Haha, easy to demonstrate. I’ll start an email thread with myself, then you see if you can join in 🤣
We can also make use of comments in the feed to build support for detecting/declaring Twts(s) were edited in a feed that are ignored by clients that don’t understand the comments. By design clients ignore comments anyway, but the parser we build for yarnd
(which I’d love to turn into a C library that others can just import) can do some interesting things here. @xuu can probably talk more on this…
I think Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa. It’s much easier to cope with the problems above, because you just ensure your client preserves the 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 😅
There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
@bender@twtxt.net The problem with the approach Email clients do things is;
- How do you come up with the message/thread id in the first place? I’m pretty sure most clients just use a UUID.
- How do you know what you’re replying to if you don’t see the message/thread id in the first place?
- How do two different users that don’t know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
@bender@twtxt.net Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.
@falsifian@www.falsifian.org Yes;
I don’t think twtxt hashes are long enough to prevent spoofing.
The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (which will happen at some point with 7, if not already).
The issue isn’t dealing with “spoofing”, it’s about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq@www.uninformativ.de points out, clients have to “obey” this unwritten rule, but they’re otherwise just arbitrary. Whereas Twt Hashes (I didn’t come up with the idea originally, some smart fellow in cryptography did) are content addressable, meaning that clients don’t have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.
@falsifian@www.falsifian.org I like this idea actually for edits.
@movq@www.uninformativ.de Care to share your thoughts here?
I don’t know what happened behind the scenes that killed off twtxt (I have a few guesses, though), but the sad truth is that it’s gone.
Agreed
@bender@twtxt.net A Fred changed its url metadata field 🤣
After unfollowing and refollowing on the new feed URL, I’m now 100% certain this is what happened for @cuaxolotl@sunshinegardens.org 🤣 The real problem is really this:
How do we identify a feed?
It cannot be the URL, because the author could change where they serve it from. This was as “good” as we could get it, but time and time again this has proven to be problematic for, well, a few folks that change their mind, which frankly should be allowed 😅
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it should put the hash of the previous Twt. Something like:
2024-09-05T13:37:40Z (edit:mp6ox4a) Hello world!
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it should put the hash of the previous Twt. Something like:
2024-09-05T13:37:40+00:00 (edit:mp6ox4a) Hello world!
To be honest, I don’t really see “editing” as a problem. I see that as a natural behavior of “forking” in the first place, that just forms a. new sub-tree. What’s really problematic here is when a feed author changes the “identity” of their feed and changes the # url =
metadata field, which is what I believe @cuaxolotl@sunshinegardens.org has just done, though I’m not 100% certain, I’m like 98% sure haha 😝
@lyse@lyse.isobeef.org Did you check your pocket? 🤣