Re: objections to webmention

On 06/03/2016 07:15 AM, Melvin Carvalho wrote:
> I've attempted to communicate for the last year, on irc and in aarons 
> github area, but its sometimes been not an optimal use of time.  So 
> I'd like to formulate my objections to webmention here, for further 
> review, with hopefully some possible solutions.
>

Hi Melvin,

You've caught me at an excellent time to write a detailed reply -- I'm 
on the plane to the F2F meeting.  This is just the right kind of work 
for this situation.  Hopefully this reply will make everything more clear.

It looks to me like your objections here are based on your design sense, 
your general sense of what good designs look like, rather than on 
specific concerns about use cases that can be addressed with one design 
versus another.

In the most recent previous discussion on this topic, at 
https://github.com/aaronpk/webmention/issues/39, I repeatedly asked you 
to provide specific use cases, to explain how developers/users would be 
affected by some change you're proposing.    I haven't seen an answer.

Perhaps you thought I was just doing that as way of dismissing you, of 
giving you busy work?    That's not the case.    I was doing it because 
by arguing from uses cases, a group has a reasonable chance of reaching 
consensus.  Arguing from design sense pretty much never leads to 
consensus.   It's a bit like the difference between science and 
religion.   With the scientific method, disagreements can usually be 
settled by replicating experiments and developing new ones.   Not so 
much with religion.

So, again, I'll say if you want to persuade the group of anything, I 
think you're going to have to lay out a use case.    I suggest taking 
some part of one of the agreed-upon users stories and show how the CR 
version of Webmention doesn't work very well but some alternate version 
you're proposing does.

Personally, I don't think you'll be able to do this.  I've been thinking 
about this space, a lot, for years, and I don't see the issues you're 
raising as the kind of issues that could lead to material use cases.   
But you're welcome to try.

A key question is what you're trying to do here.    If you want to 
improve Webmention, that's probably the way to do it.   If you just want 
to be a pain to the WG, you could raise a formal objection. (I'm not 
going to consider this "objection" a "formal objection" unless you 
specifically use that phrase.)  But unless you can be more clear in the 
way I suggest above, I don't think that'll do anyone any good.   
Normally a Formal Objection is used to make a Working Group spend some 
time seriously reconsidering some decision it made.   But I don't see a 
decision the WG has made around Webmention that it might change during a 
reconsideration, unless some new information was presented.

Another thing you could do is help move forward one of the alternatives 
to Webmention.    Rhiaro mentioned in #39 how activitypub might be just 
what you want, and I understand there are several other possible 
directions one could go.

A few more comments below, but the important part of my reply here is done.

> 1. Universality
>
> Axiom 0 of the webstates that we should use URIs to name things.

I assume you're referring to TimBL's DesignIssues/Axioms document? That 
was written 20 years ago and reflects only one person's opinion.   The 
W3C Recommendation in this space, a few years later, which resulted from 
extensive discussion among TimBL, the appointed and elected members of 
TAG, and many members of the public, was AWWW.     I think you'll find 
AWWW includes a rather more restrictive and realistic version of this axiom:


          2.1.Benefits of URIs

    The choice of syntax for global identifiers is somewhat arbitrary;
    it is their global scope that is important. TheUniform Resource
    Identifier, [URI <https://www.w3.org/TR/webarch/#URI>], has been
    successfully deployed since the creation of the Web. There are
    substantial benefits to participating in the existing network of
    URIs, including linking, bookmarking, caching, and indexing by
    search engines, and there are substantial costs to creating a new
    identification system that has the same properties as URIs.

    Good practice:Identify with URIs

    To benefit from and increase the value of the World Wide Web, agents
    should provide URIs as identifiers for resources.

    A resource should have an associated URI if another party might
    reasonably want to create a hypertext link to it, make or refute
    assertions about it, retrieve or cache a representation of it,
    include all or part of it by reference into another representation,
    annotate it, or perform other operations on it. Software developers
    should expect that sharing URIs across applications will be useful,
    even if that utility is not initially evident. The TAG finding"URIs,
    Addressability, and the use of HTTP GET and POST
    <http://www.w3.org/2001/tag/doc/whenToUseGet.html>"discusses
    additional benefits and considerations of URI addressability.

    From https://www.w3.org/TR/webarch/ <https://www.w3.org/TR/webarch/>

I think it's pretty hard to argue that the strings "source" and "target" 
in Webmention posts should be URIs based on this advice. For the cases 
where one would want them to be URIs, a standard mapping is provided.  
You could view Webmention as using URIs for this, but during the POST, 
the namespace is left implicit.

> Most standards I know at the W3C adhere to this,

Does HTML?   Does CSS?   Do any of the HTML5 APIs?    Can you name a 
non-RDF spec that does?      Probably best to stay away from XML specs, 
since their use of URIs is highly contentious.   (As I understand it, 
XML only uses URIs as web addresses and unique identifiers, not to name 
things.   The difference is perhaps pedantic, but it's clear XML specs 
don't align with the Linked Data Principles, which I think TimBL would 
agree subsumes Axiom 0 in his own personal design sense.)

Probably not worth the time to go through this, but if I had to guess, 
I'd say by count 10% of W3C specs adhere to this (my groups like RDF, 
OWL, and RIF tended to produce a dozen specs at a time) and by user 
base, 0.001% of the W3C specs adhere to this.   The weight of success is 
not on the side of this axiom, so it's not going to convince anyone.

> webmention does not use URIs for the source and target parameters.
>
> URIs can be derived out of band by reading the spec and using a 
> prefix, but this is not ideal.
>

Here's where, if you want to convince anyone, you have to tell a story 
about something that's important and significantly easier with source 
and target being URIs on the wire.   I just don't see it.

>
> 2. Using form encoded messaging for the social web
>
> Views on this differ, but IMHO it's very clear that messaging over the 
> social web according to our charter should be in JSON.
>

The chairs and I have addressed the charter issue elsewhere.  Please 
keep charter discussions in separate threads, since they involve 
different people and are reviewed differently.

> Webmention doesnt do this.
>
> To the extent that it's "just a signaling protocol" I suppose you 
> could "get away with it".  But I dont think webmention is by any means 
> just a signaling protocol. It's an attempt to standardize messaging on 
> the social web.
>

How can you claim Webmention is "an attempt to standardize messaging"?   
I don't see that in the spec.  I haven't heard that from the WG.   I 
haven't heard that from the implementors.   I haven't heard that from 
the users.   Where are you getting that?

I do, however, see how it could be *used* as part of a general messaging 
protocol:

1. System "Alice" wants to send system "Bob" some message M1
2. Alice puts M1 on the web at URL U1, being sure to include some 
metadata the links to Bob.    At a minimum, something like "To: Bob" 
(where Bob is a URL)
3. Alice does the Webmention thing, "mentioning" U1 to Bob
4. Bob gets the mention, dereferences U1, reads M1

So, in this sense, Webmention could be a key part of a web messaging 
protocol.   It's has one advantage over the much simpler approach of 
"Alice POSTS M1 to Bob", namely that Alice is confirmed as the sender.

But:
- This isn't what Webmention was designed for; it's not clear anyone 
actually wants to use it for this.
- If you do this, the actual message can be JSON or whatever Alice 
wants.   The *message* is M1, published at U1, *not* the form-encoded 
Webmention that was posted to Bob.
- If you want to do this, consider instead just POSTing M1 to Bob using 
some kind of authentication for Alice (eg OpenID Connect or WebID-TLS)

So, I see no argument here against the current design of Webmention.

>
> Possible Solutions
>
> 1. Support JSON messaging -- the W3C has innovated in this area with 
> some success
>
> 2. If we want to pass around messages using forms we should make the 
> general case robust, scalable, extensible, interoperable and 
> universal, and have webmention be an instance of such a system.  
> That's possibly outside the scope and timing of this WG, I dont know.
>

I'm not sure what those are solutions to, but they're probably not the 
problems Webmention is intended to solve.

>
> Im still being guided as to the difference between the REC and Note 
> tracks, but I'll put the suggestion out there to move webmention to a 
> note, or move it back from CR.  I'm not an expert on this aspect of 
> W3C process, but I'd like to raise these concerns to a wider audience, 
> in particular, to folks outside the indieweb community.

If you want people to pay attention to these concerns, either inside or 
outside the WG, I think you're going to have to develop a simple story 
about a problem that's solved with your modified Webmention and not 
solved with Webmention.   Or a story about how Webmention being adopted 
would do real harm to someone.

Frankly, I think you can find much better uses for your time if you want 
to work in this space, eg helping with activitypub.

         -- Sandro