# 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 21
# self = https://watcher.sour.is/conv/lnlbnsq
Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:
0. It's a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.
2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.
1. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).
3. Do we need more commandments?
Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:
0. It's a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.
2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.
1. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).
3. Do we need more commandments?
Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:
0. It's a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.
2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.
1. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).
3. Do we need more commandments?
Simplified twtxt - I want to suggest some dogmas or commandments for twtxt, from where we can work our way back to how to implement different feature like replies/treads:
0. It's a text file, so you must be able to write it by hand (ie. no app logic) and read by eye. If you edit a post you change the content not the timestamp. Otherwise it will be considered a new post.
2. The order of lines in a twtxt.txt must not hold any significant. The file is a container and each line an atomic piece of information. You should be able to run sort on a twtxt.txt and it should still work.
1. Transport protocol should not matter, as long as the file served is the same. Http and https are preferred, so it is suggested that feed served via Gopher or Gemini also provide http(s).
3. Do we need more commandments?
Well I have been working on an update of Timeline, mainly improving speed. Getting a multiple of feeds can really become a big fetch. So I would advocate for ideas to maintain performance.
Regardings your points:
1. Agreed, but at the moment date+txt creates the unique timestamp
2. Preferably newest twt as the last line, will make for more structure.
@sorenpeter I like that. It pretty much matches what I already had in mind. (The implications of part two of point 0 are obviously controversial and I don’t know if we can ever agree on that. 😅)
@sorenpeter I like that. It pretty much matches what I already had in mind. (The implications of part two of point 0 are obviously controversial and I don’t know if we can ever agree on that. 😅)
@sorenpeter I like that. It pretty much matches what I already had in mind. (The implications of part two of point 0 are obviously controversial and I don’t know if we can ever agree on that. 😅)
@sorenpeter I like that. It pretty much matches what I already had in mind. (The implications of part two of point 0 are obviously controversial and I don’t know if we can ever agree on that. 😅)
@Codebuzz Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I'm referring to the definition that it's the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.=
@Codebuzz Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I'm referring to the definition that it's the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.=
@Codebuzz Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I'm referring to the definition that it's the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.=
@Codebuzz Speed is an issue for the client software, not the format itself, but yes I agree that it makes the most sense to append post to the end of the file. I'm referring to the definition that it's the first url = in the file that is the one that has to be used for the twthash computation, which is a too arbitrary way of defining something that breaks treading time and time again. And this is the case for not using url+date+message = twthash.=
@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?
@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?
@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?
@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)in jenny as a replacement for (#twthash) and have it not care about if is http(s) or a g-protocol?
@sorenpeter As a *replacement*, it should be doable. But it won’t work *together* with hashes. So the community has to agree on one or the other first.
@sorenpeter As a *replacement*, it should be doable. But it won’t work *together* with hashes. So the community has to agree on one or the other first.
@sorenpeter As a *replacement*, it should be doable. But it won’t work *together* with hashes. So the community has to agree on one or the other first.
@sorenpeter As a *replacement*, it should be doable. But it won’t work *together* with hashes. So the community has to agree on one or the other first.