Re: standardizing webmention

Hey Melvin,

Great to hear you're so enthusiastic about the potential of webmention. I
have some responses to your points:

> 4. webmention is a call by reference type function, whereas most
functions allow both call by reference and call by value.  So when say
activity pump sends a serialized activity stream, webmention would fail.

I don't really see why this is a problem. Personally I think that AP's
sending of the whole json Activity is overkill, and sending the URIs of the
source and target of the notification to the recipent inbox endpoint would
actually suffice here.

After a server receives a webmention, it can retrieve the data about the
source by dereferencing the source URL. Dereferencing the URL is also
required in AP, to check the validity of the received Activity. So there's
not much difference in that regard. Ie. same number of requests, just AP
passes more data in the first one.

> 5. webmention objects dont return URIs, this violates web axioms, where
everything of note should have a URI

This is not correct. The webmention spec says: "The response body SHOULD
include a URL that can be used to monitor the status of the request."

> 6. webmention is not extensible over and beyond the source and target
parameters, which is problematic for any extra kind of data

Webmention is extensible by adding new parameters. See for example
indiewebcamp.com/vouch, which is an existing, implemented, extension to
webmention.

Out of interest, can you give examples of extra kinds of data you'd like to
send using a mechanism like webmention?

> 7. webmention is not namespaces, preventing both open ended scalability,
but also it's hard to translate source and target into URIs ... would
should they be?  urn:source and urn:target ... any suggestion here is
problematic.

I guess, again, use cases for sending data other than the source and target
would help to understand here. Webmention is deliberately simple. A side
effect of this is that data that the recipent is expected to consume must
be discoverable by dereferencing the source URL, so no data can be sent
from a third-party that it is not possible to validate in this way.

But, if you wanted to POST `source=
http://example.com/post&target=http://elpmaxe.org/post&foaf:maker=http://example.com/user#i`
to a webmention endpoint, there's nothing to stop you. And if you wanted to
configure your own webmention endpoint to recieve and understand such an
extension, you could. If you want to send something more complex... well,
I'd want to see a concrete rationale before I speculate more. As with any
extensions (as we've seen discussed re: AS2 extensions) you can't
necessarily rely on everyone else's endpoints understanding all of them.
For example, if my webmention endpoint recieves a `vouch` parameter, I
ignore it as I don't support vouch yet.

If you really want a namespace for `source` and `target`, perhaps
specifying a default one would work, if someone wanted to maintain it
pointing to something useful, but I don't forsee much enthusiasm for that.

The *main* deficiency I see in webmention at the moment is that if I
receive a webmention where the source is a private (access controlled)
post, my server needs some way to authenticate to validate the mention.
This is the subject of ongoing discussions in the indieweb community
though, as it's becoming an issue as more people implement private posts,
so not something that's being ignored. Others who have thought more about
this can weigh in here!

Amy

On 14 July 2015 at 12:12, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> there has been some talk about standardizing webmention as part of the
> work of this WG
>
> a few comments
>
> 1. I think webmention would really benefit from having a normative stable
> document -- when doing a search on the web there are many places you can be
> lead to, and it's really hard for a developer to know they are in the right
> place (eg webmention.org, webmention.net, indieweb wiki)
>
> 2. writing up webmention as a w3c note should not be a hard job ... it's a
> pattern that was being used 10 - 20 years ago ... for those not familiar,
> my understanding is it's a simple 2 parameter query string (ie source and
> target)
>
> 3. I am very impressed with what has been done with such a simple tech but
> I dont think it scales for a number of reasons which I'll point out:
>
> 4. webmention is a call by reference type function, whereas most functions
> allow both call by reference and call by value.  So when say activity pump
> sends a serialized activity stream, webmention would fail.
>
> 5. webmention objects dont return URIs, this violates web axioms, where
> everything of note should have a URI
>
> 6. webmention is not extensible over and beyond the source and target
> parameters, which is problematic for any extra kind of data
>
> 7. webmention is not namespaces, preventing both open ended scalability,
> but also it's hard to translate source and target into URIs ... would
> should they be?  urn:source and urn:target ... any suggestion here is
> problematic.
>
> 8 webmention does not accept the mime types being standardized in this
> group for a JSON based serialization
>
> Other than that I think it's an incredibly useful technology.  That can
> solve some but not all of the user stories and patterns this group is
> working on.  I dont think it can be a basis for a REC track social web API
> (I could be wrong there!) but im very excited about what is being done with
> it, at least as proof of concept, and would love to see something more
> official from the group on it, if that is considered appropriate -- mainly
> I think there would be a easily findable stable reference to the spec.
>