Re: objections to webmention

On 8 June 2016 at 11:28, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 4 June 2016 at 02:02, Sandro Hawke <sandro@w3.org> wrote:
>
>> 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.
>>
>
> Thanks for responding to my concerns.
>
> I was glad to learn that I am not the only person in the WG that has
> reservations on this work.
>
> I dont feel the concerns have been addressed, other than the hand waiving,
> "I dont find that compelling" argument, which can be said about anything.
> I find this dismissive, and in this group, unfortunately I am left with the
> feeling of relatively little recourse.
>
> I will leave this thread open a while to gather feedback and I think the
> advice is to document exactly what the concerns are and put them in a
> document, so they can be understood.  Which I have begun to do.  Much will
> depend on how much time I have to do this.
>
> So, I think the issue here is that there are a number of people in this
> group.  Some are coding regularly in this space, and some are familiar with
> existing W3C standards that solve this problem, but few are both.  So
> perhaps that can also be documented.
>

To clarify this is not a "formal" objection, because:

1 It would need to be clearly documented
2 It would need to be worthy of the attention of a wider audience (director
+ w3c member) -- that's not clear to me at this point
3 It would need fail to be resolved in the WG (I think we still have space
to do that)

I dont think 1/2/3 are currently met at this time.  So I will try and build
out (1) because I think there are legitimate concerns around interop

My recommendation at this point, is for this work to be a Note, and leave
the door open for further standardization.


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