Re: objections to webmention

It also lets people mute threads...
On Jun 11, 2016 11:38 AM, "Aaron Parecki" <aaron@parecki.com> wrote:

> In particular with admin rights being granted to people with a clear
>> conflict of interest who close down and lock issues before they have been
>> fully discussed.
>
>
> You may not realize it, but you're making a pretty serious accusation
> here, and also misrepresenting the situation.
>
> For some background, the "w3c-social" GitHub account (which is where the
> specific instances I'm assuming you are referencing happened) is not
> "official" in any way, and probably never should have been created in the
> first place. That said, it is also entirely reasonable that the editor of a
> spec has admin rights on the spec's repository. This is currently done in
> one of two ways, either a GitHub repo lives under the editor's personal
> account, or it lives under the actual official w3c account and the editors
> are granted admin rights there.
>
> The issues on GitHub that were "closed down" were closed for very specific
> reasons. I have closed issues on GitHub when the original topic brought up
> in the first comment had been addressed. I have also closed issues when the
> original topic had been addressed and the thread continued with other
> unrelated discussion. In every case, I have encouraged people commenting on
> the thread to open a *new* issue with the new topic. If we don't do this,
> then the GitHub thread becomes no better than the mailing list, where
> discussion is disorganized and nearly impossible to find again in the
> future. The whole point of using GitHub issues for discussion is to have a
> URL for each specific topic, where discussion at that URL relates to the
> topic, so that it can be found and referenced easier in the future. There
> is no cost, and only benefits, to having new topics raised as new issues so
> that each has its own URL.
>
> If you feel there are specific instances where your original issue on
> GitHub was not fully addressed, then please bring those to our attention,
> preferably by opening a new issue and referencing the old one in the
> comment. However keep in mind that the group can address an issue without
> actually doing what you suggest in the issue. A perfectly acceptable
> outcome for an issue is for the group to disagree with the suggestion and
> not to incorporate it. The important part is that the issue is discussed in
> the group, so if you feel like a particular issue has not been given a
> proper audience in the group then that is worth correcting.
>
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk <http://twitter.com/aaronpk>
>
>
> On Sat, Jun 11, 2016 at 1:29 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>> On 8 June 2016 at 16:50, Sandro Hawke <sandro@w3.org> wrote:
>>
>>>
>>>
>>> On June 8, 2016 4:53:53 AM PDT, Melvin Carvalho <
>>> melvincarvalho@gmail.com> wrote:
>>> >On 8 June 2016 at 13:12, Ben <ben@thatmustbe.me> wrote:
>>> >
>>> >> > 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?
>>> >>
>>> >No no!
>>> >
>>> >I think it's good work, in general.  Im happy that it was done.  Ideal
>>> >way
>>> >is to resolve issues here.  It's slightly awkward with tantek having
>>> >boycotted the mailing list, but I dont give up hope!
>>> >
>>>
>>> The preferred place to discuss issues on a specific spec is github.    I
>>> opened an issue for you for this, to help encourage that, but then
>>> eventually closed it because you weren't using it.
>>>
>>
>> The github process is rather hit and miss.  It works well in some groups
>> and even here with james snell, however some of us have made an effort to
>> use other repos and the feeling is that the process is broken.  In
>> particular with admin rights being granted to people with a clear conflict
>> of interest who close down and lock issues before they have been fully
>> discussed.
>>
>> Your own words on the github process described in the wiki : "The rules
>> are TERRIBLY explained and justified"
>>
>> Some in the WG have made an effort on github but found the process not to
>> be a productive use of time.  Additionally, for structural problems in a
>> specification, I might suggest that mailing list which has a wide
>> readership can be helpful.  FWIW, I've been contacted out of band by a
>> number of people in the space, supporting the points I make.
>>
>> This thread has been valuable in that it has established clearly that
>> webmention is an extensible messaging system.  As such it ought to at a
>> minimum be compatible with the social syntax this group is chartered to
>> create.
>>
>>
>>>
>>> >Just not seeing why it should be REC, rather than Note, at this point.
>>> >
>>>
>>> Because it appears it will meet all the criteria for a Rec.    Otherwise
>>> it's like a 5th grade student being enrolled in the 2nd grade.    You seem
>>> to think it really still belongs in 2nd grade but it's already met the
>>> objective criteria for graduating 2nd and seems fairly likely to do the
>>> rest soon.
>>>
>>> >What I'd like to see is webmention having a mapping to linked data,
>>> >interoperate with that, and the millions of sites that use it
>>> >(including
>>> >facebook and google), and also to have its form encoded version, seems
>>> >to
>>> >be the best of all worlds.
>>> >
>>>
>>> Just because two systems use JSON-LD doesn't make them interoperable.
>>>
>>> Acting as if it does is the Semantic Web "handwaving" or "pixie dust"
>>> that some folks find offensive.   It's what creates the "RDF allergy".
>>>
>>> There is adoption for ogp and schema.org in part because they're a
>>> whole lot more constrained than just using RDF.  The other constraints are
>>> necessary to provide interop.
>>>
>>> If you can show a plausible way to provide them for webmention, then
>>> I'll be intrigued.    I've thought about it a lot and don't think it's
>>> possible.
>>>
>>>     - Sandro
>>>
>>> >
>>> >
>>> >> 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
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>>
>>>
>>
>