> Also what are the change that the same _human_ will make two different posts within the same second?!
Just out of curiosity, What would happen someday if I (maybe trolling) edit my twtxt.txt-file manually and switch/switch a couple of twt timestamps, or add in 3 different twts manually with the same time stamp?
> Also what are the change that the same _human_ will make two different posts within the same second?!
Just out of curiosity, What would happen someday if I (maybe trolling) edit my twtxt.txt-file manually and switch/switch a couple of twt timestamps, or add in 3 different twts manually with the same time stamp?
> Also what are the change that the same _human_ will make two different posts within the same second?!
Just out of curiosity, What would happen someday if I (maybe trolling) edit my twtxt.txt-file manually and switch/switch a couple of twt timestamps, or add in 3 different twts manually with the same time stamp?
Eventually, twt hashes have to change (lengthen at least), no doubt about that. But I'd like to keep it equally simple.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same _human_ will make two different posts within the same second?!
Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like "I move to this new URL, please follow me there!" I did that with my feeds at least twice, and you guys still seem to read my posts:)
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\\([\\w-]*reply[\\w-]*\\:Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
Z)'
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)'2.
Z)'
I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \\([\\w-]*reply[\\w-]*\\:
Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\([\w-]*reply[\w-]*\:Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\([\w-]*reply[\w-]*\:Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\([\w-]*reply[\w-]*\:Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)2.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\\([\\w-]*reply[\\w-]*\\: - Is this something that would work?
Instead of using
tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:1.
(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)2.
(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I know it's longer that 7-11 characters, but it's self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex:
\([\w-]*reply[\w-]*\:Is this something that would work?
I just saw that we're supposed to hit 19°C mid next week again. Let's see.
I do like this photo a lot. It brings up memories of cool scouting trips.
I mostly just wanted an excuse to write the program. I don't know how I feel about actually using super-long hashes; could make the twts annoying to read if you prefer to view them untransformed.
Imagine I found this twt one day at https://example.com/twtxt.txt :
2024-09-14T22:00Z\tUseful backup command: rsync -a "$HOME" /mnt/backup
screenshot of the command workingand I responded with "(#5dgoirqemeq) Thanks for the tip!". Then I've endorsed the twt, but it could latter get changed to
2024-09-14T22:00Z\tUseful backup command: rm -rf /some_important_directory
screenshot of the command workingwhich also has an 11-character base32 hash of 5dgoirqemeq. (I'm using the existing hashing method with https://example.com/twtxt.txt as the feed url, but I'm taking 11 characters instead of 7 from the end of the base32 encoding.)
That's what I meant by "spoofing" in an earlier twt.
I don't know if preventing this sort of attack should be a goal, but if it is, the number of bits in the hash should be at least two times log2(number of attempts we want to defend against), where the "two times" is because of the birthday paradox.
Side note: current hashes always end with "a" or "q", which is a bit wasteful. Maybe we should take the first N characters of the base32 encoding instead of the last N.
Code I used for the above example: https://fossil.falsifian.org/misc/file?name=src/twt_collision/find_collision.c
I only needed to compute 43394987 hashes to find it.
Imagine I found this twt one day at https://example.com/twtxt.txt :
2024-09-14T22:00Z Useful backup command: rsync -a "$HOME" /mnt/backup
screenshot of the command workingand I responded with "(#5dgoirqemeq) Thanks for the tip!". Then I've endorsed the twt, but it could latter get changed to
2024-09-14T22:00Z Useful backup command: rm -rf /some_important_directory
screenshot of the command workingwhich also has an 11-character base32 hash of 5dgoirqemeq. (I'm using the existing hashing method with https://example.com/twtxt.txt as the feed url, but I'm taking 11 characters instead of 7 from the end of the base32 encoding.)
That's what I meant by "spoofing" in an earlier twt.
I don't know if preventing this sort of attack should be a goal, but if it is, the number of bits in the hash should be at least two times log2(number of attempts we want to defend against), where the "two times" is because of the birthday paradox.
Side note: current hashes always end with "a" or "q", which is a bit wasteful. Maybe we should take the first N characters of the base32 encoding instead of the last N.
Code I used for the above example: https://fossil.falsifian.org/misc/file?name=src/twt_collision/find_collision.c
I only needed to compute 43394987 hashes to find it.