Content-Type should probably even include the charset=utf-8 as we learned recently. :-) Iff you want to keep the UTF-8 encoding mandatory. It doesn't say anything about it in that document.
reply-to can come anywhere in the message text? Most examples even put it at the very end. Why relax that? It currently has to be at the beginning, which I think makes parsing easier. I have to admit, at the end makes reading the raw feed nicer. But multi-line messages with U+2028 ruin the raw feed reading experience very quickly.
And yea since yarnd has a store it's a bit easier to support edit / delete actions 😅
And yea since yarnd has a store it's a bit easier to support edit / delete actions 😅
What about the timestamp format? Just verbatim as it appears in the feed (what I would recommend) or any other shenanigans with normalization, like
+00:00 → Z?An append style is not required, btw. If one uses prepend style feeds, the new URL simply comes at the beginning of the file, where the old URL is further down.
Clients must use the full-length hash in their storages, but only use the first eleven digits when referencing? This differentiation is a bit odd.
2024-09-07T12:55:56Z 🥳 NEW FEED: @<twtxt http://edsu.github.io/twtxt/twtxt.txt>
2024-09-07T12:55:56Z 🥳 NEW FEED: @<kdy https://twtxt.kdy.ch/twtxt.txt>
2024-09-07T12:55:56Z\t🥳 NEW FEED: @<twtxt http://edsu.github.io/twtxt/twtxt.txt>
2024-09-07T12:55:56Z\t🥳 NEW FEED: @<kdy https://twtxt.kdy.ch/twtxt.txt>
2024-09-07T12:55:56Z 🥳 NEW FEED: @<twtxt http://edsu.github.io/twtxt/twtxt.txt>
2024-09-07T12:55:56Z 🥳 NEW FEED: @<kdy https://twtxt.kdy.ch/twtxt.txt>
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
reply-to, where in the ReplyTo Extension it's without the hyphen. (But they also use different values after the colon. :-))
yarnd and I suspect jenny too. and as indicated in here quite easy to have a reference implementation written in Bash with standard UNIX tools.~_
yarnd and I suspect jenny too. and as indicated in here quite easy to have a reference implementation written in Bash with standard UNIX tools.~_
$ ./twtxt-v2.sh reply 242561ce02d "Cool! 👌"
Posted twt with hash: b2c938f9838
...
$ ./twtxt-v2.sh timeline
...
prologic@twtxt.net [2024-09-22T07:26:37Z] <242561ce02d> Okay folks, I've spent all day on this today, and I _think_ its in "good enough"™ shape to share:
**Twtxt v2**:
- Specification: https://docs.mills.io/uJXuisaYTRWYDrl8A2jADg?both
- implementation: https://gist.mills.io/prologic/afdec15443da4d7aa898f383f171ec1b
prologic@localhost [2024-09-22T07:51:16Z] <b2c938f9838> Cool! 👌 (reply-to:242561ce02d)
$ ./twtxt-v2.sh reply 242561ce02d "Cool! 👌"
Posted twt with hash: b2c938f9838
...
$ ./twtxt-v2.sh timeline
...
prologic@twtxt.net [2024-09-22T07:26:37Z] <242561ce02d> Okay folks, I've spent all day on this today, and I _think_ its in "good enough"™ shape to share:
**Twtxt v2**:
- Specification: https://docs.mills.io/uJXuisaYTRWYDrl8A2jADg?both
- implementation: https://gist.mills.io/prologic/afdec15443da4d7aa898f383f171ec1b
prologic@localhost [2024-09-22T07:51:16Z] <b2c938f9838> Cool! 👌 (reply-to:242561ce02d)
Twtxt v2:
- Specification: https://docs.mills.io/uJXuisaYTRWYDrl8A2jADg?both
- implementation: https://gist.mills.io/prologic/afdec15443da4d7aa898f383f171ec1b
Twtxt v2:
- Specification: https://docs.mills.io/uJXuisaYTRWYDrl8A2jADg?both
- implementation: https://gist.mills.io/prologic/afdec15443da4d7aa898f383f171ec1b
yarnd, hosted it temporarily (_I think locally_) and used it to poison the caches of a few production pods.Thankfully the gossip protocol used by
yarnd as part of its "peering" between pods isn't fully trusted, twts are not archived for example into permanent storage. So the moment my pod re-fetched my own feed, the spoofed Twt was obliterated 😅Eventual consistency 🤣
yarnd, hosted it temporarily (_I think locally_) and used it to poison the caches of a few production pods.Thankfully the gossip protocol used by
yarnd as part of its "peering" between pods isn't fully trusted, twts are not archived for example into permanent storage. So the moment my pod re-fetched my own feed, the spoofed Twt was obliterated 😅Eventual consistency 🤣
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
\n \n [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
\n \n [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
\n \n [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
\n \n [(#otuupfq) @shreyan Ahh 👌]
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
Le me is worried! 😅
Le me is worried! 😅
Le me is worried! 😅
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I hope to see @david @movq @lyse @xuu @sorenpeter and hopefully others too @aelaraji @falsifian and anyone else that sees this! 🙏 We're _hopefully_ going to primarily discuss the future of Twtxt and the last few weeks of discussions 🤣
- Event: Yarn.social Online Meetup
- When: 28th September 2024 at 12:00pm UTC (midday)
- Where: Mills Meet : Yarn.social
- Cadence: 4th Saturday of every Month
Agenda:
- Let's talk about the upcoming changes to the Twtxt spec(s)
- See #xgghhnq
#Yarn.social #Meetup
I hope to see @david @movq @lyse @xuu @sorenpeter and hopefully others too @aelaraji @falsifian and anyone else that sees this! 🙏 We're _hopefully_ going to primarily discuss the future of Twtxt and the last few weeks of discussions 🤣
- Event: Yarn.social Online Meetup
- When: 28th September 2024 at 12:00pm UTC (midday)
- Where: Mills Meet : Yarn.social
- Cadence: 4th Saturday of every Month
Agenda:
- Let's talk about the upcoming changes to the Twtxt spec(s)
- See #xgghhnq
#Yarn.social #Meetup
- We increase the Hash length from
7 to 11.- We formalise the Update Commands extension.
- We amend the Twt Hash and Metadata extension to state:
> Feed authors that wish to change the location of their feed (_once Twts have been published_) must append a new
# url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.This has implications of the "order" of a feed, and we should either do one of two things, either:
- Mandate that feeds are append-only.
- Or amend the Metadata spec with a new field that denotes the order of the feed so clients can make sense of "inline" comments in the feed. -- This would also imply that the default order is (_of course_) append-only. Suggestion:
# direction = [append|prepend]
- We increase the Hash length from
7 to 11.- We formalise the Update Commands extension.
- We amend the Twt Hash and Metadata extension to state:
> Feed authors that wish to change the location of their feed (_once Twts have been published_) must append a new
# url = comment to their feed to indicate the new location and thus change the "Hashing URI" used for Twts from _that_ point onward.This has implications of the "order" of a feed, and we should either do one of two things, either:
- Mandate that feeds are append-only.
- Or amend the Metadata spec with a new field that denotes the order of the feed so clients can make sense of "inline" comments in the feed. -- This would also imply that the default order is (_of course_) append-only. Suggestion:
# direction = [append|prepend]
1. Add the ability to allow feed address changes.
2. Increase hash from 7 to 11, and/or change the hashing algorithm to something else, better.
3. Implement
movq (I simply can’t mention while on mobile) second option (the one you like, which maintains content addressing).
yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:- What breaks
Basically I'm at a point where spending time on this is going to provide very little value, there are assumptions made in the lextwt parser, assumptions made in yarnd, assumptions in the way storage is done and the way threading works and things are looked up. There are far reaching implications to changing the way Twts are identified here to be "location addressed" that I'm quite worried about the amount of effort would be required to change
yarnd here.
yarnd to see how many things would break and how many assumptions there are around the idea of "Content Addressing"; here's where I'm at so far:- What breaks
Basically I'm at a point where spending time on this is going to provide very little value, there are assumptions made in the lextwt parser, assumptions made in yarnd, assumptions in the way storage is done and the way threading works and things are looked up. There are far reaching implications to changing the way Twts are identified here to be "location addressed" that I'm quite worried about the amount of effort would be required to change
yarnd here.
(#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
(#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
(#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
(#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?