Webmention explicitly supports create, update, delete as a server to server protocol

[tantek]

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.

[rhiaro]

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.

[tantek]

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.

[rhiaro]

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.

[rhiaro]

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".

[dissolve]

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

[tantek]

"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.

[rhiaro]

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.

[dissolve]

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.

[rhiaro]

Only "delivery" and "subscription" are the federation protocol? So Webmention covers the delivery part of that. Which seems adequate.. I'll add subsections to the table for vocab/syntax, social api (CRUD) and federation protocl (delivery, subscription). I'm a bit uncomfortable with client/server differentiation, because a webmention sender or and LDN sender (for example) could be a client (ie. a JS in browser app, or a desktop app, or a native mobile app) or it could be a script running on a server, so I think dividing them up that way is misleading or at least confusing.

…

On 20 April 2017 at 21:51, Ben Roberts ***@***.***> wrote: 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcdNYWengt-Lgfh9tFkAnF08IK5XofZks5rx2LugaJpZM4NBPLm> .

[dissolve]

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.

[rhiaro]

Huh? I'm happy to decouple based on social API vs federation protocol. But whether technically a client or server is implementing each part is irrelevant.

…

On 20 April 2017 at 22:20, Ben Roberts ***@***.***> wrote: 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcdNfAVNUcF_1Ce3CvJBoA07gY5TrQWks5rx2mZgaJpZM4NBPLm> .