Re: objections to webmention

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

Isn't that effectively saying you want it resolved outside of the working
group?
On Jun 8, 2016 6:59 AM, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:

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