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@twtxt.andros.dev this is actually already achieved with yarnd
@eapl.me@eapl.me@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@twtxt.net 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@twtxt.andros.dev Would it help if I documented the two protocols that yarnd uses today for this “distributed network”? 🧐
@prologic@twtxt.net yes! Of course. However give me some time, I want to define a small proposal for the Registry (v2?)
I’d like to know more about what andros and prologic are talking about, I feel lost.
“This will be managed by Registries.” Are we talking about these registries?
https://twtxt.readthedocs.io/en/latest/user/registry.html
@eapl.me@eapl.me@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”.