# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
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
# url = https://example.com/new/twtxt.txt
# url = https://example.com/brand-new/twtxt.txt
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.
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.
> 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? 🤔
> 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? 🤔
> 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? 🤔
> 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? 🤔
Btw, @prologic, 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.
Btw, @prologic, 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.
Btw, @prologic, 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.
Btw, @prologic, 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.
Maybe you could even just use the time, and rely on -mentions to disambiguate. Not sure how that would work out.
Though I kind of like the idea of twts being immutable. At least, it's clear which version of a twt you're replying to (assuming nobody is engineering hash collisions).
1. Key rotation. I'm not a security person, but my understanding is that it's good to be able to give keys an expiry date and replace them with new ones periodically.
2. It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.
Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)
It's nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you don't trust https to do that (maybe you don't like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ 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.
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ 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\t(#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.
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ 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.
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 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 '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.
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 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 '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.
> “I think Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa \n
Absolutely not! Maybe this is something best talked. 😅
> “I think Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa […]
Absolutely not! Maybe this is something best talked. 😅
> “I think Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa […]
Absolutely not! Maybe this is something best talked. 😅
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...
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...
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.
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.
- 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)
- 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)
So, how to reply, and engage with something that can potentially change? I think the email based
message-id, and in-reply-to would work best, without the rigid boundary of a hash that’s bound to break on edit.
> “\n they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.”
It isn’t about trust, is it? There has to be some kind of check to verify the hash is valid, no?
> “[…] they can trust that the hash is a cryptographic representing of the thread they’re replying to, no matter what.”
It isn’t about trust, is it? There has to be some kind of check to verify the hash is valid, no?
> 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 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.
> 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 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.
What I like about this is that clients that don't know this convention will still stick it in the same thread. And I feel it's in the spirit of the old pre-hash (subject) convention, though that's before my time.
I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.
> But the great thing about the current system is that nobody can spoof message IDs.
I don't think twtxt hashes are long enough to prevent spoofing.
What I like about this is that clients that don't know this convention will still stick it in the same thread. And I feel it's in the spirit of the old pre-hash (subject) convention, though that's before my time.
I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.
> But the great thing about the current system is that nobody can spoof message IDs.
I don't think twtxt hashes are long enough to prevent spoofing.
> 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.
> 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.
#catsoftwtxt
/https://baldo.cat/media/photos/IMG_1894.jpeg) #catsoftwtxt
#catsoftwtxt
> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
You already can ask your most passionate followers to support you: You can ask for donations.
I regularly donate to people if their content is great and if they actually ask for donations (many just don’t). The platforms for that already exist, I think. 🤔
I’m not interested in the slightest in stuff that has a paywall. “Subscribe for more content!” No, why, go away. Pages that do this immediately feel shady and not trust-worthy. 🤔
> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
You already can ask your most passionate followers to support you: You can ask for donations.
I regularly donate to people if their content is great and if they actually ask for donations (many just don’t). The platforms for that already exist, I think. 🤔
I’m not interested in the slightest in stuff that has a paywall. “Subscribe for more content!” No, why, go away. Pages that do this immediately feel shady and not trust-worthy. 🤔
> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
You already can ask your most passionate followers to support you: You can ask for donations.
I regularly donate to people if their content is great and if they actually ask for donations (many just don’t). The platforms for that already exist, I think. 🤔
I’m not interested in the slightest in stuff that has a paywall. “Subscribe for more content!” No, why, go away. Pages that do this immediately feel shady and not trust-worthy. 🤔
> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
You already can ask your most passionate followers to support you: You can ask for donations.
I regularly donate to people if their content is great and if they actually ask for donations (many just don’t). The platforms for that already exist, I think. 🤔
I’m not interested in the slightest in stuff that has a paywall. “Subscribe for more content!” No, why, go away. Pages that do this immediately feel shady and not trust-worthy. 🤔