# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 20
# self = https://watcher.sour.is/conv/rqg5cxa
falsifian
www.falsifian.org
View Thread
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.


2. 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.


3. 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 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.)


4. 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.=
prologic
twtxt.net
View Thread
@falsifian 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
prologic
twtxt.net
View Thread
@falsifian 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
prologic
twtxt.net
View Thread
> 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 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 🤣
prologic
twtxt.net
View Thread
> 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 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 🤣
prologic
twtxt.net
View Thread
@falsifian 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.~
prologic
twtxt.net
View Thread
@falsifian 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.~
prologic
twtxt.net
View Thread
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
View Thread
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
View Thread
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
falsifian
www.falsifian.org
View Thread
@prologic

> 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.)
bender
twtxt.net
View Thread
@prologic what if I copy your uuid, and use it on my feed? What happens then? Also, was the dot after the timestamp intended?
prologic
twtxt.net
View Thread
@bender 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.
prologic
twtxt.net
View Thread
@bender 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.
prologic
twtxt.net
View Thread
@falsifian 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
prologic
twtxt.net
View Thread
@falsifian 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
prologic
twtxt.net
View Thread
> 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 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.
prologic
twtxt.net
View Thread
> 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 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.
prologic
twtxt.net
View Thread
> 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_).
prologic
twtxt.net
View Thread
> 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_).