# 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 6
# self = https://watcher.sour.is/conv/vdkllnq
prologic
twtxt.net
View Thread
TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

- Roots: (tno:N) (implicit ofeed=self).
- Replies: (tno:N) (ofeed:<url>).
- Clients: increment tno locally for new threads, copy tags on reply.
- Subjects optional, not required.

...=
prologic
twtxt.net
View Thread
Example:

Alice starts thread #42:


2025-09-25T12:00:00Z (tno:42) Launching storage design review.


Bob replies:


2025-09-25T12:05:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) I think compaction stalls under load.


Carol replies to Bob:


2025-09-25T12:08:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) Token bucket sounds good.
prologic
twtxt.net
View Thread
This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.
movq
www.uninformativ.de
View Thread
@prologic That’s a completely flat threading model (you can’t reply to replies). Is that intentional?
prologic
twtxt.net
View Thread
@movq Yes it's kind of terrible 😞 -- Let's not do this 🤣
alexonit
twtxt.alessandrocutolo.it
View Thread
@prologic I think a counter in the client is not a good choice given the decentralized nature of twtxt, especially if someone use multiple cients together.

After thinking about it for a while I got to two solutions:

Proposal 1: Thread syntax (using subject)

Each post have an implicit and an *optional* explicit root reference:

- Implicit (no action needed, all data required are already there)
- URL + timestamp

- Explicit (subject required)
- Identity (client generated)
- External reference
- Random value

We then add include a "root" subject in each post for generating explicit theads:
1. [ROOT_ID] (REPLY_ID): simpler with no need of prefixes
2. (root:ROOT_ID) (reply:REPLY_ID): more complex but could allow expansions
- (rt:ROOT_ID) (re:REPLY_ID): same but with a compact version
- ($ROOT_ID) (>REPLY_ID): same but with a single characters

Each post can have both references, like the current hash approach the reference can be treated as a simple string and don't have a real meaning.

Using a custom reference this way allows a client to decide how to generate them:
- Identity: can be a content hash or signature or anything else, without enforcing how it is generated we can upgrade the algorithm/length freely
- External references: can be provided from another system (Eg. 7e073bd345, *yarnsocial/yarn* latest commit)
- Random value: like a UUID (Eg. 9a0c34ed-d11e-447e-9257-0a0f57ef6e07)

Proposal 2: Threaded mentions (featuring zvava)

Inspired by @zvava's solution it could be simplified into: #<nick url#timestamp> or #<url#timestamp>

It can be shown like a mentions or hidden like a subject.

If we're using thinking of using a counter in the client, I think there's no point in avoiding the timestamp anymore.*