# 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 8
# self = https://watcher.sour.is/conv/2a3pssq
Thanks for sharing that diagram, it's very insightful, makes me think a lot :)
Long post ahead to clarify my thoughts...
There are many moving parts but we could simplify them as:
> Twtxt starts with a txt file stored in a Web server. Inside that file, there are URLs to other Web servers with many twt files.
> By Web, I oversimplify it as HTTP(S), DNS, UTF-8, and all the technology required to transfer those text files.
> Protocol would be "a defined set of rules and regulations that determine how data is transmitted".
> Format is the "shape" of the text file.
Although most of the twtxt files are not interconnected with each other, a few are, creating a micro-network effect. Seeing replies to a friend of yours, and wanting to follow that new URL.
Somehow we got the URLs and are valid (not depending on a central directory).
I think from the strict technical definition, a distributed system would require to have copies of the text files from other servers, made available to 3rd parties. At least with twtxt-php
I'm not thinking of that model. There is only 1 available source for each following URL. There is no redundancy but some local cache.
About distribution, the definition of 'distributing control and decision-making, reducing reliance on a central authority' is hard for me to connect with twtxt. Let me explain a bit:
On a twtxt text file and most CLI clients, the rule is "Follow these URLs with a compatible format and show me their content. If it's not compatible or it's not accessible show an error", and I think that's it.
You cannot restrict who can see your file. So there is no need for a central authority in a pure sense. There is no moderation, privacy policies, muting a whole server, etc. Some kind of censorship could arrive by IP or domains like what happens on the Web so I'm ignoring it for the moment.
I find a similarity with an Atom feed but with the ability to follow each other using software to manage the replies, discovery, and such.
On Yarn or Masto we have Pods and Instances. Each server is a 'mini central authority' for its members if I'm seeing it correctly.
The server defines a set of rules for all its users, although some personal parameters could be tweaked. We have a Local timeline, helping with discoverability. The content is tied to the software. If the server is down, usually all these users are affected.
Could we say this model is semi-centralized or semi-decentralized? How do we define how decentralized is something?
Leaving philosophical questions aside, with twtxt-php
I don't know how to categorize it. It's not distributed for sure. I could say it's decentralized: One micro-server for each URL file.
The URLs are compatible or not, so there is no need for authority, other than a protocol to intercommunicate.
š¤
I should make a new diagram with all these ideas over the weekend š
Thanks for sharing that diagram, it's very insightful, makes me think a lot :)
@eapl.me yarnd
is centralised if you run a large instance with a large number of users.The design of the software itself discourages an operator from doing this, the more users you have, the more resources the pod would consume. It was never designed for this.
yarnd
is however strictly decentralised, with _some_ distributed features that allow "peering pods" to talk to each other, often exchanging "missing Twts" among peers. This is useful to correct chains or fill in missing roots -- Because the whole "network" is decentralised. This is one of the downsides of a decentralised system, so we had to figure out a "middle ground".
@eapl.me yarnd
is centralised if you run a large instance with a large number of users.The design of the software itself discourages an operator from doing this, the more users you have, the more resources the pod would consume. It was never designed for this.
yarnd
is however strictly decentralised, with _some_ distributed features that allow "peering pods" to talk to each other, often exchanging "missing Twts" among peers. This is useful to correct chains or fill in missing roots -- Because the whole "network" is decentralised. This is one of the downsides of a decentralised system, so we had to figure out a "middle ground".
@eapl.me yarnd
is centralised if you run a large instance with a large number of users.The design of the software itself discourages an operator from doing this, the more users you have, the more resources the pod would consume. It was never designed for this.
yarnd
is however strictly decentralised, with _some_ distributed features that allow "peering pods" to talk to each other, often exchanging "missing Twts" among peers. This is useful to correct chains or fill in missing roots -- Because the whole "network" is decentralised. This is one of the downsides of a decentralised system, so we had to figure out a "middle ground".