# 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 13
# self = https://watcher.sour.is/conv/ep5rg4q
What does the #twtxt community think about having a p2p database to store all history? This will be managed by Registries.
What does the #twtxt community think about having a p2p database to store all history? This will be managed by Registries.
pls elaborate on a 'p2p database', 'all story' and 'Registries'.
My first thought takes me to something like secure-scuttlebutt which it's painful to sync data using clients, and too slow compared to downloading a text file.
Also I'd like for twtxt to avoid becoming an ActivityPub. Works well but it's uses too many resources IMO.
https://kingant.net/2025/02/mastodon-the-cost-of-running-my-own-server/
I'm defending being able to self-host your Web client (like you'd do with a Wordpress, twtxt is a micrologging, at the end), instead of federated instances, so in a first thought I'd say Registries have many disadvantages being the first one that someone has to maintain them active.
@andros this is actually already achieved with yarnd
@eapl.me@eapl.me I don't think there's anything wrong with an optional distributed network with participating members of the community. As long as it's optional.
@prologic If it develops, and I'm not saying it will happen soon, perhaps Yarn could be connected as an additional node. Implementation would not be difficult for any client or software. It will not only be a backup of twtxt, but it will be the source for search, discovery and network health.
@prologic If it develops, and I'm not saying it will happen soon, perhaps Yarn could be connected as an additional node. Implementation would not be difficult for any client or software. It will not only be a backup of twtxt, but it will be the source for search, discovery and network health.
@andros Would it help if I documented the two protocols that yarnd uses today for this "distributed network"? 🧐
@prologic yes! Of course. However give me some time, I want to define a small proposal for the Registry (v2?)
@prologic yes! Of course. However give me some time, I want to define a small proposal for the Registry (v2?)
@eapl.me@eapl.me I replied in the fork, but essentially there's no reason we can't support two different models here. We already do this anyway with numerous single-user, single hosted and managed feeds + a bunch of multi-user yarnd pods that form a "distributed network".