Re: Webmention and Anchors

Hi Peter,

First of all I want to be sure, that when you say draft, you mean Rec, as
webmention is at full recommendation status now,
https://www.w3.org/TR/webmention
Just want to be sure we are looking at the same version of the document.

To your question about notifying more than one endpoint of webmentions.
This was considered but ultimately deemed unnecessary.
Its trivial to make a webmention endpoint that will have the sole job of
relaying webmentions to multiple other endpoints.

Requiring clients to check and send to multiple endpoints put a lot more
burden on the client as they would have to parse the entire
document when only the head might have sufficed, and have to determine what
happens when only one of the endpoints is receiving, etc.

As to why now allow compliant implementations to do it, well there is
certainly nothing from stopping them from doing that, but they really
shouldn't have to.
The receiver should only be publishing one, and if they are publishing
multiple they cannot and should not be expecting them all to receive
webmentions.

There are security issues with this too, if a comment has rendered html in
it (though not recommended) it can start receiving copies of all
webmentions to
that page.  This would allow for inadvertent DDOSing as the comment could
contain numerous copies of a target domain as rel=webmention.


On your question about fragments,
The text says that
What a "valid resource" means is up to the receiver.

The fragment SHOULD be ignore when checking to see if the URL is supported
though.
So in other words, you should not be rejecting foourl#anchor because foourl
does not have that anchor on the page, only look at whether foourl
is a valid URL that supports webmentions.

Keep in mind, this is a SHOULD, so, while its strongly recommended that you
don't consider the
fragment when determining a valid target, if you have a very good reason
to, you can.


Getting back to your original interest, the way comments have been done in
the indieweb, where this spec grew out of, is for markup on the comment's
source to indicate specifically what it is replying to.   There is a lot of
info on the wiki there if you want to get some ideas.  Take a look at these
pages in particular.
http://indieweb.org/in-reply-to
http://indieweb.org/comments

Thanks,
Ben Roberts

On Mon, Apr 3, 2017 at 6:41 PM, Peter Gerdes <gerdes@invariant.org> wrote:

> I didn’t initially notice the mention of fragment identifiers in 3.2.1.
> However, this text is ambiguous merely saying "Note that a target URL may
> contain a fragment identifier, and if the receiver limits which URLs can
> receive Webmentions, the fragment *SHOULD* be ignored when checking if
> the URL is supported.”
>
> Arguably this implies that using the fragment identifier to determine
> which webmentions the reciever will accept so it too implicitly conflicts
> with the use I was suggesting..  Not sure
>
> Peter
>
> P.S. Ignore my P.S. on the last post.  The FAQ explained why the spec
> doesn’t allow multiple endpoints to be notified for a single link. However,
> this explanation doesn’t really hold up.  Resolving a redirect isn’t
> particularly cheaper than notifying a (non-redirected) endpoint and if
> webmention implementations follow webbrowsers that means ~20 potential
> redirects could be chained.
>
> Why not at least ALLOW compliant implementations to notify multiple
> endpoints and maybe even require them to notify the first 5?  Sure you
> can’t be sure that any implementation will really do that but why not give
> them the chance?
>
> P.P.S. In my first post I wrote 3.12 when I should have written 3.1.2.
> Sorry.
>
>
> On Tue, Apr 4, 2017 at 1:20 AM Peter Gerdes <gerdes@invariant.org> wrote:
>
>> I see that in the draft webmention spec an implementation must preserve
>> the query string but no mention is made about anchors.
>>
>> In particular I was interested in the use case of lightweight
>> notification of comment replies which usually occur many to a page.
>>
>> If the text in 3.12 was modified so that if URL=foourl#anchor then only
>> the descendants of #anchor in HTML were searched for an <a> or <link>
>> element with rel=“webmention” this could be usefully used as a comment
>> reply notification.
>>
>> In such a use case each comment (on say a blog) would allow the user to
>> enter a webmention url which would be added (but not necessarily displayed)
>> to the displayed comment.  Any reply to a comment could then include a link
>> to it’s parent (or parents) so a conforming implementation could trigger a
>> webmention to inform the parent poster of the reply.
>>
>> (Yes, I realize ActivityPub or some other pub/sub architecture would no
>> doubt handle a richer version of notification but it is also far more
>> complex.)
>>
>> Anyway there may be good reasons the draft doesn’t allow this but I
>> figured I would throw the question/use-case out there.
>>
>> Peter
>>
>> P.S. Am I misreading the draft or does it allow only a single url to be
>> notified via webmention for each link in a post?  In other words I can’t
>> decide that I want both service A and service B to recieve a webmention
>> whenever someone links to my homepage.  Is there any reason for this
>> restriction?
>>
>