benhylau
commented
3 years ago Very relevant article about Webmentions, and what we are trying to do here: https://allinthehead.com/retro/378/implementing-webmentions
From the article:
As social media sites gained traction, those communities moved away from blog commenting systems. Instead of reacting to a post underneath the post, most people will now react with a URL someplace else. That might be a tweet, a Reddit post, a Facebook emission, basically anywhere that combines an audience with the ability to comment on a URL.
This is why we think it is an ideal standard for bridging fragmented DWeb systems.
The flow, also from article:
The flow goes something like this.
- Frankie posts a blog entry.
- Alex has thoughts in response, so also posts a blog entry linking to Frankie’s.
- Alex’s publishing software finds the link and fetches Frankie’s post, finding the URL of Frankie’s Webmention endpoint in the document.
- Alex’s software sends a notification to the endpoint.
- Frankie’s software then fetches Alex’s post to verify that it really does link back, and then chooses how to display the reaction alongside Frankie’s post.
The end result is that by being notified of the external reaction, the publisher is able to aggregate those reactions and collect them together with the original content.
In our case, we want to write the collected reactions on the DWeb, and serve them over all the protocols, so different DWeb ecosystems and social networks can have a shared view of all the same dynamic social content.
RangerMauve
Motivations & goals
The Social API allows sharing of social messages across fragmented DWeb networks using different protocol. The design relies on Webmention and Microformats2.
Traditionally, websites employing Webmention either have to run a backend process or defer to a centralized third-party service to process Webmentions. We are exploring how we can operate an ephemeral service to process Webmentions and utilize the DWeb as a shared content store. Being able to "like" or "repost" immutable content also opens up a lot of longer term possibilities, such as versioned cross-referencing or linking monetization with social interactions.
This also solves one of the great shortcomings of the DWeb: fragmentation of social spaces. Fragmentation limits authors' abilities to build large audiences or capture useful metrics about the success of their work. With Webmention and direct payments like Web Monetization to facilitate a social and feedback layer, we can build strong disintermediated and federated networks with rich feedback loops.
Design proposal
The Distributed Press server's Social API HTTP endpoint will receive Webmentions from any website, then store a copy in our web server, pinned onto a Hypercore Key and an IPNS DNSLink. The server essentially ingests social messages on the HTTP endpoint and seed them on DWeb networks.
The tentative design is to store Webmentions as structured files on disk in a hierarchy that makes them easy to reconcile with the posts they belong to. By relying on files over complex database servers, we’ll ensure that the content can be stored and replicated on IPFS and Hypercore. (Review unwalled.garden for possible schema.)
What can we do with it?
Each post in the published static website essentially has an associated "Dropbox" seeded on IPFS and Hypercore, storing Webmentions-based social messages. When a reader loads up this website, on WWW or DWeb, they can also see the Webmentions collected for each post.
This "DWeb Dropbox of social messages" bridge conversations together, without centralizing them in a single database. Clients can also choose not to broadcast their discussions (e.g. a thread on Secure Scuttlebutt is meant to be semi-private). We will implement the standard interactions enabled by Webmentions (like, reply, quotation, citation, share) with basic Microformats2 vocabularies.
With our Social API, DWeb publications may receive existing Webmentions from the IndieWeb community, and also create social connections and references to that existing content base.