sorenpeter @darch.dk
 (1y ago)

(#j63urka) (#<2024-09-24T12:45:54Z https://twtxt.net/user/prologic/twtxt.txt>) @prologic@twtxt.net Iā€™m not really buying this one about readability. Itā€™s easy to recognize that this is a URL and a date, so you skim over it like you would we mentions and markdown links and images. If you are not suppose to read the raw file, then we might a well jam everything into JSON like mastodon

#gg7ykkq
sorenpeter @darch.dk
 (1y ago)

(#a73p7ma) (#<2024-09-24T12:44:35Z https://twtxt.net/user/prologic/twtxt.txt>) There is a increase in space/memory for sure. But calculating the hashes also takes up CPU. Iā€™m not good with that kind of math, but itā€™s a tradeoff either way.

#ipfcooq
sorenpeter @darch.dk
 (1y ago)

(#rksyfja) (#<2024-09-24T12:39:32Z https://twtxt.net/user/prologic/twtxt.txt>) @prologic@twtxt.net It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile ā€“ Basically what @movq@www.uninformativ.de also said. Iā€™m also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You donā€™t have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.

#lpc2tia
sorenpeter @darch.dk
 (1y ago)

(#bz2mpca) (#<2024-09-24T12:34:31Z https://twtxt.net/user/prologic/twtxt.txt>) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarndā€™s WebMentions work, so I decide to make my own, which Iā€™m the only one usingā€¦

I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We donā€™t need near realtime. We just need a way to notify someone that someone they donā€™t know about mentioned or replied to their post.

#nmi6qwq
sorenpeter @darch.dk
 (1y ago)

Some more arguments for a local-based treading model over a content-based one:

  1. The format: (#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.

  2. Having something like (#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.

  3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you donā€™t follow.

#knryyga
lyse @lyse.isobeef.org
 (1y ago)

(#5sdepuq) @prologic@twtxt.net What should happen if the archive chain is detected to be broken? I donā€™t think that including the hash in the prev field does really help us in reality. What if messages in the archive feed themselves got lost? You canā€™t detect this unless youā€™ve already known about them. I reckon we can simply use the relative path and call it good. I know, I know, we have this format already today. But in my opinion, the hash does not add value.

#oxluy3q
lyse @lyse.isobeef.org
 (1y ago)

(#5sdepuq) @prologic@twtxt.net The 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.

#tatesua
lyse @lyse.isobeef.org
 (1y ago)

(#5sdepuq) @prologic@twtxt.net For hash calculation we could maybe rethink the newlines and use tabs instead. This is more in line with the twtxt file format itself. With tabs it also is much closer to the registry format (minus the nick).

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.

#lcizupq
sorenpeter @darch.dk
 (1y ago)

(#s2dhlvq) @movq@www.uninformativ.de I cases of these kind of ā€œabuseā€ of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.

#vp2b7ha
sorenpeter @darch.dk
 (1y ago)

(#crmwgxq) Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<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?

#wbjsona
lyse @lyse.isobeef.org
 (1y ago)

(#rqkdcfa) @prologic@twtxt.net Let me try:

Invent anything you want, say feed A writes message text B at timestamp C. You simply create the hash D for it and reply to precisely that D as subject in your own feed E with your message text F at timestamp G. This gets hashed to H.

Now then, some a client J fetches your feed E. It sees your response from time G with text F where in the subject you reference hash D. Since client J does not know about hash D, it simply asks some peers about it. If it happens to query your yarnd for it, you could happily serve it your invention: ā€œYou wanna know about hash D? Oh, thatā€™s easy, feed A wrote B at time C.ā€

The client J then verifies it and since everthing lines up, it looks legitimate and puts this record in its cache or displays it to the user or whatever. It does not even matter, if the client J follows feed A or not. The message text B at C with hash D could have just deleted or edited in the meantime.

Congrats, you successfully spread rumors. :-D

#zr6spqq
lyse @lyse.isobeef.org
 (1y ago)

(#rqkdcfa) @prologic@twtxt.net Just what @bender@twtxt.net did. :-D If heā€™d additionally serve the fake message from his yarnd twt endpoint, everybody querying that hash from him (or any other yarnd that synced it in the meantime) would believe, that I didnā€™t like Australians.

In fact, I really donā€™t. I loveā€™em! 8-)

We would need to sign each message in a feed, so others could verify that this was actually part of that feed and not made up. But then we end up in the crypto debate for identities again, which Iā€™m not a big fan of. :-)

I just want to highlight, one might get a false sense of message authenticity, if one just briefly looks at the hashes.

#iovmszq
lyse @lyse.isobeef.org
 (1y ago)

(#fj7dppq) It just occurs to me weā€™re now building some kind of control structures or commands with (edit:ā€¦) and (delete:ā€¦) into feeds. Itā€™s not just a simple ā€œadd this to your cacheā€ or ā€œreplace the cache with this set of messagesā€ anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.

#s2bqszq
lyse @lyse.isobeef.org
 (1y ago)

(#fj7dppq) @movq@www.uninformativ.de Thanks for the summary!

So, what would happen if there is no original message anymore in the feed and you encounter an ā€œeditā€ subject? Since you cannot verify that the feed contained it in the first place, would you obey it?

Some feed could just make a client update something from a different feed. In the cache, the client would need to store in a flag that this message was updated, so that when it later encounters the message from the real feed, it has a chance of reverting that bogus edit. Hmm. The devil is in the detail.

Itā€™s much easier with a delete subject. When it finds the message in its cache and the feeds match, remove it. Otherwise, just ignore it.

#y6idegq