@eapl.me@eapl.me There are several points that I like, but I want to highlight number 7. https://text.eapl.mx/a-few-ideas-for-a-next-twtxt-version #twtxt
@andros@twtxt.andros.dev Reading… 👀
@eapl.me@eapl.me Some really good idea in this post of yours 👌👌
# default_lang = en
# discovery_url = https://example.com/discovery/
# follow = alice https://example.com/alice.txt ABCDEF12
# follow = alice gemini://example.com/alice.txt
# avatar = https://example.com/avatar/alice.png
# avatar = gemini://example.com/avatar/alice.png
1 2025-03-03T15:00:00-04:00 {lang=en} Hello, world! Welcome to my twtxt feed. UTF-8 check: é, ö, ü.
2 2025-03-03T15:05:00-04:00 {lang=es} ¡Hola, mundo! This tweet is in Spanish.
3 2025-03-03T15:10:00-04:00 {url=ABCDEF12,id=1} Replying to tweet 1 using its URL hash.
4 2025-03-03T15:15:00-04:00 {edited=1} This tweet has been edited once.
5 2025-03-03T15:20:00-04:00 {lang=fr} Bonjour le monde! A French twt overriding the default language.
6 2025-03-03T15:25:00-04:00 Regular twt without metadata defaults to en.
Example feed I guess? ☝️
looks good to me!
About alice’s hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I’ll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.
Also, watching your example I’m thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1}
That way, the ‘full twt ID’ could be 96473B4F_1.
@eapl.me@eapl.me@eapl.me@eapl.me I kind of like the idea of 96473B4F_1 – That is SHA256SUM(feed_url)_<monotomic_feed_post_id>
This seems to be capable of supporting edits as you noted. But I need to think a bit more (~2am here now) of whether this can be abused in any way… The advantage of Content-based Addressing (hashing the content) is that the hash is then immutable, meaning that we can have integrity that the hash actually represents that content from that author at that time.
yep! Enjoy your rest, let’s discuss it later
a few async ideas for later
The editing process needs a lot of consideration and compromises.
From one side, editing and deleting it’s necessary IMO. People will do it anyway, and personally I like to edit my texts, so I’d put some effort on make it work.
Should we keep a history of edits? Should we hash every edit to avoid abuse? Should we mark internally a twt as deleted, but keeping the replies?
I think that’s part of a more complete ‘thread’ extension, although I’d say it’s worth to agree on something reflecting the real usage in the wild, along with what people usually do on other platforms.
For point 1 and others using the metadata tags. we have implemented them in yarnd as [lang=en][meta=data]
TwtAttrs
https://git.mills.io/yarnsocial/go-lextwt/pulls/17
Actually it was your old feed on eapl.mx