Webmention incompatible with modern, dynamic content

[ELLIOTTCABLE]

Just ran across this thanks to @tommorris on Twitter; halfway into your page, and I've already come across a ridiculously glaring problem with this idea:

Your design seems stuck in the noughties. Very little important on the web is happening in the REST, HTTP-request-for-every-action, static-web-content-generated-by-the-server space; and even less looks to be happening in that field in the future. Not everything on the Internet is a static “forum” or “blog” anymore.

In more direct terms: if a developer were to choose any non-static methodology to build their application, they would be precluded from easily using WebMention. Anything involving content generation via communication over WebSockets or even old-school “AJAX” is immediately precluded by your design.

Most particularly, I, as a developer, cannot submit a WebMention to a foreign API, if any of the content doing the mentioning is dynamically generated, on the client. It must be generated server-side, and served statically; else, your specification dictates that my content be treated as spam.

---

I don't like offering criticism without demonstrating that there's better ways, so I'll put forth here several iterations on your design, changes I might suggest to solve this issue (provided ordered from “those I suggest most heartily” to “those that are barely acceptable.”)

• Abandon spam-checking altogether. rel="nofollow" is enough; if there's no benefit to spammers wasting expensive compute resources posting links, then you may assume that, for the most part, they will not do so (unless they are extraordinarily dim; and economic Darwinian selection will remove these from the problem-causing pool rather quickly.)

  For that matter, designing the need for reciprocation into the spec is inherently flawed (in my rather irrelevant opinion). Leave that up to the implementation: if somebody cares whether mentions are reciprocated, let them operate a checkbox somewhere to say so. Not all “mentions” of your content on the web will be, or even should be, reciprocated. Assuming that to be the case in the spec is a mistake.

• Allow the sender to provide an alternate-URL for the content; perhaps a statically-generated version of similar content (obviously, this is not percent-encoded):

  Content-Type: application/x-www-url-form-encoded
  
  source=http://alices.host/alice/post/42&
  alt_source=http://alices.host/alice/post/42.json;content-type=application/json
  target=http://bobs.host/bob/post/2

  Worth mentioning, although obvious: this loses much of the “spam-blocking” you're hoping (futilely, in my opinion) to achieve; it's entirely easy to spoof. However, if the implementation wished to use source-content-awareness for something constructive instead of defensive, then this might be useful (ekeing out the prose around the mention … parsing for further information about users that may have made the mention on the page … etceteras.)

• Augment the design with some sort of trust-network for hosts doing the ‘mentioning’ of content. Bloaty, messy, but about the best you can do if you want ensured-reciprocation on the modern web.
• Modify the spec to suggest that implementations put non-reciprocative links into some sort of human-moderation queue, instead of suggesting that it directly deny them with an error message.

---

Finally. I hope you'll forgive the direct, almost offensive tone, and take this advice for what it is: I see designs like this all too often; and you, my friends, are trying to build a specification that you're suggesting for use across the entire web. That's an important responsibility, and (assuming you're lucky enough to succeed), it's tremendously important that … to put it unkindly … you don't fuck it up this badly.

I'm offering this feedback partially because I want you to succeed, but also because I don't want you to succeed in a way that further limits the technological development of the web.

[aaronpk]

You seem to bring up at least half a dozen points in this issue, so it makes it difficult to reply to them individually. Ironically, this issue itself does in fact have a public URL, and if each of your arguments were separate issues I would be able to comment on them all individually with new permalinked pages.

---

• WebMention is intended to be used for content that has permalinks. If I can’t get it with a GET request, it’s not on the web. (https://vimeo.com/42225804)
• WebMention is intended to be a simple notification mechanism saying that X linked to Y
• Having the alternate content URL like you suggests violates DRY: http://microformats.org/wiki/dry
• Several of us have discussed adding a trust network layer on top to do things like auto-approval of publishing comments. Note that even after sending a webmention successfully, that does not imply that a "comment" is going to appear on the target

[ELLIOTTCABLE]

@aaronpk they're all arguments supporting one actual problem. (=

1. “If I can’t get it with a GET request, it’s not on the web.” That's your opinion, and not backed by the real world. You, putting your boundaries on what is and isn't the web, isn't going to stop the web from developing in a different direction. Which is exactly my point! Better to be more flexible, to allow for things outside your personal box around ‘what the web is.’
2. “WebMention is intended to be a simple notification mechanism saying that X linked to Y.” Understood, and at no point did I debate this. I understand the premise of the spec.
3. “Having the alternate content URL like you suggests violates DRY.” A perfectly valid point, and a reason why I, myself, don't particularly like that solution. I'm simply trying to offer you alternatives to the only one I support; that being the removal of necessitated-reciprocation entirely.
4. “Several of us have discussed adding a trust network layer on …” It's nothing like an innovative idea, I didn't believe it to be new. I'm just pointing out that it'd be a way to mitigate the things you're worried about, like generative spam, without your spec contributing to the holding-back of the web.
5. “… that does not imply that a ‘comment’ is going to appear on the target.” Good! I would hope not! The blogger community already has trackbacks, we have no need for a simple clone of that concept. I would hope you're envisioning much more innovative interactions between mentioned content than appending reciprocative return-links at the bottom of static content. :)

[sandeepshetty]

@ELLIOTTCABLE thanks for taking the time to write this up. The effort you put into it is the only reason I'm forgiving the "direct, almost offensive tone", and taking this advice for what it is.

Very little important on the web is happening in the REST, HTTP-request-for-every-action

eh, the web IS REST, no? I'm guessing you're talking about the non-addressable "stuff" which I don't have a name for but it sure ain't "THE WEB".

In more direct terms: if a developer were to choose any non-static methodology to build their application, they would be precluded from easily using WebMention

Yes. Don't use it if it doesn't work for you. Webmention is just a simpler replacement for Pingback. It doesn't pretend to be anything else.

Abandon spam-checking altogether. rel="nofollow" is enough; if there's no benefit to spammers wasting expensive compute resources posting links, then you may assume that, for the most part, they will not do so (unless they are extraordinarily dim; and economic Darwinian selection will remove these from the problem-causing pool rather quickly.)

I'm guessing you haven't managed a blog or wiki or any sort of site that people can post content to. "Compute resources" are not expensive for spammers. I also wonder why "economic Darwinian selection" haven't got rid of the email/blog/forum/mailing-list/wiki SPAM problems yet?

But in all seriousness, the suggestion that rel="nofollow" is enough is interesting but makes the mistake of confusing the means with the end. The goal of spamming is not to get inbound links. It's to get an audience (either via search traffic or blog/wiki/forum/mailing-list/email readers).

Bloaty, messy, but about the best you can do ...

No thanks. That's exactly the opposite of what webmention wants to be.

P.S. Why is your username all caps? Is it an acronym for something? I'm intrigued.

[sandeepshetty]

@ELLIOTTCABLE

For that matter, designing the need for reciprocation into the spec is inherently flawed (in my rather irrelevant opinion). Leave that up to the implementation: if somebody cares whether mentions are reciprocated, let them operate a checkbox somewhere to say so. Not all "mentions" of your content on the web will be, or even should be, reciprocated.

The verification step is a SHOULD (made even more explicit in v0.2) which allows for an implementation to ignore it.

However, leaving it up to the implementation also means that you will have interop issues if you choose to send a webmention that expects you to reciprocate, when you don't. Conversely, if NOT reciprocating is the default you can never expect anyone to reciprocate.

It is the reciprocation that makes interesting things like The First Federated #Indieweb Comment Thread and Really Simple Social Blogging (see implementation here: http://www.sandeep.io/39) possible.

If you have a real-world use case where you want to use webmention and it's not working for you, I would be more than happy to look into it and see if it's something webmention should support.

[sandeepshetty]

@ELLIOTTCABLE

However, if the implementation wished to use source-content-awareness for something constructive instead of defensive, then this might be useful (ekeing out the prose around the mention … parsing for further information about users that may have made the mention on the page … etceteras.)

The "interesting things" I mentioned in my previous comment use source-content-awareness for something constructive instead of defensive and v0.2 also talks about picking up data from source.

[tommorris]

I was going to post this last night but forgot. Without getting into the argument about the merits of actually serving content as HTML vs. serving it as a blob of JavaScript that might at some point render into some text (Schrodinger's web page?), I'd note that in practice, the verification step is generally not done synchronously with the request.

You get a 202 Accepted if your request is well formed and the URLs look like actual URLs. Most actual implementations stick the parsing and processing on a queue.