Webmention explicitly supports create, update, delete as a server to server protocol
tantek opened this issue · comments
Webmention explicitly supports create, update, delete as a server to server protocol (API) and this should be reflected both in the summary table, and in prose.
E.g. this table: https://w3c-social.github.io/social-web-protocols/#requirements
The Webmention row should have an "X" in the Create Update Delete columns.
Create: https://www.w3.org/TR/webmention/#webmention-verification refers to displaying comments, likes, and other creating of responses on a post. In addition Brid.gy in particular supports Webmention (receiving) as a server to server API to enable servers to federate their content to create posts on other servers (in particular popular social media silos.)
Update: https://www.w3.org/TR/webmention/#sending-webmentions-for-updated-posts and https://www.w3.org/TR/webmention/#updating-existing-webmentions
Delete: https://www.w3.org/TR/webmention/#sending-webmentions-for-deleted-posts and the item starting with "If it received a 410 Gone" in https://www.w3.org/TR/webmention/#updating-existing-webmentions
These Webmention "CUD" APIs are interoperably supported by numerous implementations as shown in the results in https://webmention.net/implementation-reports/summary/ which is also worthy of mentioning in this overview.
Thanks! I added updating and deleting to the Delivery section.
But I'm trying really hard to differentiate creating content when I refer to CUD, and keep this separate from the notion of delivering notifications. Webmention does not specify how to create, update or delete a content object like a blog post on a server (this is what Micropub does) it just alerts a server to content that has been created, updated, or deleted elsewhere.
Bridgy uses Webmention as a trigger to create new content in silos, but doing this is not part of the Webmention spec itself.
The introduction to the 'publishing' section tries to cover this differentiation, but if it's still not clear then I really want to improve the wording there to make this difference as unfuzzy as possible.
I'm having trouble with the differentiation that I think you're trying to draw, since from the user's perspective, they are creating content on their local device, and their device is delivering it to a server. In this regard, micropub does CUD client->server, and webmention does CUD server->server.
I'm expecting this model of local is where you create etc. will become more the norm as more things support offline first etc.
You say: "Webmention does not specify how to create, update or delete a content object" but that's exactly what it says in the sections I linked. It specifies how webmention receivers should handle display/create, update, and delete semantics of a content object on that receiver / server.
You're right that webmention allows for delivery/notification-only implementations, however, in practice most implementations have implemented Webmention CUD as specified, even if optional, so that's what deserves to be documented in the overview as what works today.
If Webmention gets an X in the CUD boxes in the table, then so do LDN and WebSub. That makes the table basically meaningless and I might as well drop it altogether.
Is there a line to be drawn between creating your own content on your own server, and having someone else's server create a copy of your content on their server?
For some definition of "own".
There always has been as far as our requirements have been concerned. We went down a long rabbit hole with this debate before, let's not do it again. We are charter for two different APIs for client to server and server to server, so it might make sense for the table to reflect that
"If Webmention gets an X in the CUD boxes in the table, then so do LDN and WebSub. " can you point to implementation reports of multiple implementations that pass test suites for update and delete in LDN and WebSub?
Because AFAIK there is no specific update nor delete protocol documented in either LDN or WebSub, much less tested, or implemented.
My point (per the URLs already shared above) is that Webmention deserves "X"s in those columns because it has:
- explicitly documented Update and Delete in its protocol for senders AND receivers (URLs above)
- tests in its test suite for that Update and Delete functionality for senders and receivers
- numerous implementations that pass those tests and interoperate, frankly more than any other spec / test suite from this WG
None of the other specs you mention are even close those criteria.
@dissolve the point is that Webmention has "CUD" explicitly in specification, tests, and impls, and that should be more than good enough for a summary table in an overview document.
the point is that Webmention has "CUD" explicitly in specification, tests, and impls, and that should be more than good enough for a summary table in an overview document.
It's CUD for something that's not "your" content in "your" datastore though, that's the difference I'm trying to get at.
I'm not saying webmention isn't used in practice for CUDing content on other people's servers even though none of that infiormation is included in the payload nor a requirement of the spec (there's nothing that says once you have verified the source you have to keep it, and update only applies if you keep it).
I'm saying there's an important distinction between the micropub kind of CUD and the webmention kind of CUD. That's what I think @dissolve means with C2S vs S2S as well.
My point is that the chart makes webmention look like it does very little, when in reality it, with basic HTTP, covers all of the federation protocol which is a major part of the deliverables of the WG. The chart should make that clear, I would personally put them in to subsections of format, client to server, and server to server. Might be useful to include Microformats and HTTP, to basically show in an overview how these bits and pieces actually work in the case of the various ecosystems.
As I said, we have gone through that all before, while you can make a hodge-podge setup that will work, that sort of goes against the idea of decoupling all these pieces section of the charter.
I like the new top-level headers to group the features.
I agree that Webmention doesn't fall under the "Social API" header, but I do think that Create (maybe instead of Delivery), Update and Delete should all be sub-features of Federation. Webmention covers those three features of Federation.
But actually storing the source isn't required by the spec. I added https://w3c-social.github.io/social-web-protocols/#webmention-updates to discuss the storing/display of the source that happens in practice.
Actually storing the webmention data (in a manner that can be retrieved again in future) isn't required by the spec either. An update webmention or a delete webmention is a new webmention. Existing webmentions don't get updated or deleted. If they do, it's an implementation detail, not part of the spec as I read it.
I also added
If a server also implements [Webmention] it should propagate the updates to anyone who received Webmentions for the original.
to Publishing->Updating and the equivalent for Publishing->Deleting.
I honestly think that adding this to the table is just more confusing with regards to what is being updated/deleted.
It's true that it's not required by the spec, but it's done by every implementation in practice. Webmention is also used to update and delete items when federating social content between servers. The value of including it in the table is that it better describes the existing ecosystem of how the specs relate to each other.