Re: standardizing webmention

On 14 July 2015 at 18:54, Amy G <amy@rhiaro.co.uk> wrote:

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

Yes, but your personal preferences and others may differ.


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

I understand it's deliberately simple.  But that comes at the cost of
scalability.  For example sending a direct message via a JSON activity
stream, is one of the user stories.  Webmention is too basic to understand
that.  If it were to understand AS2 and JSON as a MUST, that's a different
story.


>
> But, if you wanted to POST `source=
> http://example.com/post&target=http://elpmaxe.org/post&foaf:maker=http://example.com/user#i`
> <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.
>>
>
>