More thoughts about changes to twtxt (as if we haven’t had enough thoughts):

1. There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:
   

1a. Better and longer hashes.

1b. New possibly-controversial ideas like edit: and delete: and location-based references as an alternative to hashes.

1c. Best practices, e.g. Content-Type: text/plain; charset=utf-8

1d. Stuff already described at dev.twtxt.net that doesn’t need any changes.

1. We won’t know what will and won’t work until we try them. So I’m inclined to think of this as a bunch of draft ideas. Maybe later when we’ve seen it play out it could make sense to define a group of recommended twtxt extensions and give them a name.

2. Another reason for 1 (above) is: I like the current situation where all you need to get started is these two short and simple documents:
   https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
   https://twtxt.readthedocs.io/en/latest/user/discoverability.html
   and everything else is an extension for anyone interested. (Deprecating non-UTC times seems reasonable to me, though.) Having a big long “twtxt v2” document seems less inviting to people looking for something simple. (@prologic@twtxt.net you mentioned an anonymous comment “you’ve ruined twtxt” and while I don’t completely agree with that commenter’s sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core.)

3. All that being said, these are just my opinions, and I’m not doing the work of writing software or drafting proposals. Maybe I will at some point, but until then, if you’re actually implementing things, you’re in charge of what you decide to make, and I’m grateful for the work.

@falsifian@www.falsifian.org We’ve been doing this for years:

There are lots of great ideas here! Is there a benefit to putting them all into one document? Seems to me this could more easily be a bunch of separate efforts that can progress at their own pace:

See https://dev.twtxt.net

Deprecating non-UTC times seems reasonable to me, though.) Having a big long “twtxt v2” document seems less inviting to people looking for something simple. (@prologic@twtxt.net you mentioned an anonymous comment “you’ve ruined twtxt” and while I don’t completely agree with that commenter’s sentiment, I would feel like twtxt had lost something if it moved away from having a super-simple core

See https://yarn.social (especially this section: https://yarn.social/#self-host) – It really doesn’t get much simpler than this 🤣

@falsifian@www.falsifian.org I don’t have a problem with continuing the way we have been for the past ~4 years, little extensions and improvements that we try along the way. That has worked quite well 💪 As a blind person myself, I can totally empathise with reading a full (lots of text) spec. Even if we decide to combine all the ideas into a full fleshed out v2 spec, it might be worthwhile having a cut-down version that is as simple as it can be a no less.

For example a v2 spec might just simply mandate the following as a starting point:

cat <<EOF
# nick = $USER
# avatar = https://example.com/$USER.png
# description = Hi 👋 I'm Bob!
# uuid = 7E9BC039-4969-4296-9920-4BACDBA8ED5C

2024-09-28T11:19:25+10:00   Hello World!
EOF > ~/public_html/twtxt.txt

And:

• Serve your file with Content-type: text/plain; charset=utf-8

@prologic@twtxt.net

See https://dev.twtxt.net

Yes, that is exactly what I meant. I like that collection and “twtxt v2” feels like a departure.

Maybe there’s an advantage to grouping it into one spec, but IMO that shouldn’t be done at the same time as introducing new untested ideas.

See https://yarn.social (especially this section: https://yarn.social/#self-host) – It really doesn’t get much simpler than this 🤣

Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)

That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)

@prologic@twtxt.net what if I copy your uuid, and use it on my feed? What happens then? Also, was the dot after the timestamp intended?

@bender@twtxt.net Bahahahahahahaha 🤣

This is why we need “authenticity” 🤣 Yes if you copied my feed’s UUID, then you’d end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌

Also, was the dot after the timestamp intended?

No, sorry.

@falsifian@www.falsifian.org Yeah I agree with this actually (introducing too many changes at once is often a bad idead):

but IMO that shouldn’t be done at the same time as introducing new untested ideas

Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)

I argue you do. It’s nice to have a “@nick@domain` a feed author prefers to be called by, rather than you just making shit™ up haha 😝

It’s also quite nice to have a visual representation of the feed too. description can be optional.

Without this, feeds are a bit too “bland” IMO.`

That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)

It’s for this reason I’d like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I think the effort involved in “precise threading” (using content addressing) becomes much easier to “author” (note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt).