RE: Building a Decentralized Webring
This is a response to Building a Decentralized Webring over on 0x19.org.
I have been interested in decentralized and federated internet technologies for a good while, but - as established - they all suffer from similar issues of high traffic loads and faux-decentralization. I always thoroughly enjoy reading proposed solutions to this issue, especially simple and elegant ones built on existing, standardized technology. This is also one of the main reasons why I decided to participate in the lainchan webring.
The author of the article which this post is a response to also posted a follow-up white paper[1] on the issue, which elaborates upon the design laid out in the original article. It fixed the main shortcoming of the dring[2] specification, but in my opinion also maintains a significant level of unneeded complexity - mostly in the form of a record of nodes two hops away, which would have to be updated periodically.
I don't see the advantage of keeping a record of nodes other than direct neighbors, as the system is only designed for facilitating web navigation rather than actually transmitting messages to a specific destination. The primary reason would be to use it as a 'cache' to reduce network traffic, but the straight forward solution would be to either add any missing nodes to its list of direct neighbors, or simply expect users to navigate to a neighbor in order to view its neighbors.
The specification explicitly states that "every peer is its own authority on its own record"[3]. A reasonable design principle, which is somewhat undercut by sites hosting a compiled list of its neighbors' record of neighbors. It seems like a lot of work for little gain. Eliminating the 2hop.txt file would come with several advantages; no cronjob necessary, no accidental DDoS concern, no risk of the record being outdated, and no scripting/cgi necessary.
Additionally, I would suggest consolidating the self.txt and 1hop.txt into a single json or xml file. Json is a more expressive format than CSV, which would facilitate extending the spec with optional features - such as an RSS feed, site banner, or more detailed contact information. It is also easier to parse than plain text. Something like the following:
{ "title": "test", "description": "placeholder description", "url": "https://web.site", "feed": "https://web.site/rss", # optional attribute "banner": "https://web.site/banner.png", # optional attribute "peers": [ {"title": "foo", "url": "https://foo.site", "banner": "https://foo.site/banner.png"}, {"title": "bar", "url": "https://bar.site"} ] }
Webrings generally lack a strong social element, which in my opinion is the main disadvantage compared to the fediverse. To remedy this I would propose to add an RSS component to the specification, which would allow users to more easily follow the goings on and interact with each other more directly. Sites could advertise their RSS feed in their identity file, and the record of neighbors could then easily be utilized to build a complete list of RSS feeds associated with the webring. The <id> tag of the RSS feed would be required to match the URL in the identity file.
The main advantages over the current lainchan webring are the abilities to build a canonical map or record of the webring, and to automatically check the availability of nodes. This would preferably be done very rarely, so keeping an up-to-date cache would most likely be overkill and pollute the webring with unnecessary traffic. As a general rule, the system ought to stay as lean as possible while leaning into its advantages.
Footnotes
[1]
A more robust proposal by the same author, entitled Unnamed Webring Project
[2]
The dring project gitlab repo.
[3]
Unnamed Webring Project, section 3. How the network actually works.