#social 2015-11-30

2015-11-30 UTC
bblfish, bengo, shepazu, cwebber_remote, bengo_, tsyesika and shevski joined the channel
#
Loqi Mcarvalh made 1 edit to [[Socialwg/2015-12-01]] https://www.w3.org/wiki/index.php?diff=86948&oldid=86944
Arnaud, shevski, jasnell, shevski_ and shepazu joined the channel
#
Loqi Rhiaro made 1 edit to [[Socialwg/2015-12-01]] https://www.w3.org/wiki/index.php?diff=86949&oldid=86948
#
Loqi Rhiaro made 1 edit to [[Socialwg/2015-12-01]] https://www.w3.org/wiki/index.php?diff=86950&oldid=86949
#
Loqi Rhiaro made 1 edit to [[Socialwg/2015-12-01]] https://www.w3.org/wiki/index.php?diff=86951&oldid=86950
#
ben_thatmustbeme rhiaro: regarding your proposal, sounds good except for "All issues are closed by working group consensus only, as with Tracker issues." I think that needs to be a judgement call, if there is some dissent, the dissentors can bring it for WG consensus
#
ben_thatmustbeme but not waste telcon time until then
shevski joined the channel
#
rhiaro ben_thatmustbeme: I don't mind what the process *is* so long as there is a process so that everyone is on the same page. That works, so long as 'dissentors' wanting to bring it for consensus are not ignored and have their issues closed anyway :)
#
ben_thatmustbeme certainly. it is certainly good to state about driving rather than halting.
bengo joined the channel
#
ben_thatmustbeme or rather, driving in the over all sense, halting certain parts of a spec is certainly logical
#
ben_thatmustbeme remove X because it creates problem Y
#
ben_thatmustbeme but people need to be amenable to other sides of the convo
#
ben_thatmustbeme actually, is the repo only open to WG? i mean anyone can comments, certainly a significant number of them have come from a person outside the group
#
csarven ben_thatmustbeme FYI since you brought it up: I didn't create a new comment (just to keep the conversation flow as is) but updated my existing one: https://github.com/w3c-social/webmention/issues/1#issuecomment-159755367 . See the Edit.
#
ben_thatmustbeme csarven: rel i think fits better since its a descript of a relation though i don't know if that gets confusing since its re-using another vocab, as I said, i'm not one of those vocabulary experts
#
rhiaro ben_thatmustbeme: Pretty sure it's okay for anyone to create issues
#
ben_thatmustbeme by the way, csarven does your endpoint follow shortlinks?
#
rhiaro ben_thatmustbeme: it's just contributions that we have to watch out for for IPR stuff
#
ben_thatmustbeme ahh i see
#
ben_thatmustbeme cwebber_remote: do you have any place for issues / questions for activity pump?
#
csarven ben_thatmustbeme Not sure what you mean when you say "re-using another vocab"
#
ben_thatmustbeme i'm guessing cwebber is in transit though
#
rhiaro try cwebber_remote
#
rhiaro oh you did
#
rhiaro goes back to sleep
#
ben_thatmustbeme hehe rhiaro
#
ben_thatmustbeme csarven: rel= alread has a registry of possible values, but this would be a different set, might be confusing
bengo joined the channel
#
csarven ben_thatmustbeme No, my endpoint doesn't. However, I think the library that I'm using may be (I can't recall now) following the URLs as long as the first match is made.
#
csarven So, if the target URL exists, it will go for it.. and if that happens to be redirecting, it probably goes with it up to a certain numbe rof redirects I imagine.
#
csarven phpish/webmention /http /link_header
#
csarven re: rel values. You can use whatever you want in there. It is not a taxonomy.
#
ben_thatmustbeme so for you, you follow redirects iff target is given
#
ben_thatmustbeme and fair point, just wanted to raise that as a concern
#
csarven Yes, that's my preference.
#
csarven I'm interested in what is the claim and whether that can be checked and verified. Not interested in arbitrary ways in which 'it could be true'. It either is, or isn't.
#
ben_thatmustbeme thats the part sandro and i got to with that seperate thread, if you have a redirect you must provide target
#
ben_thatmustbeme so, trying to put it in your terms here, if i Like two URLs in one post, both URLs on your site, is that two claims or one?
#
csarven Can oyu give me example.org examples?
#
csarven B likes Sa, B likes Sb ?
#
csarven Those are two separate statements, yes.
#
ben_thatmustbeme i create a post where I, (B) likes example.org/post/1 (Sa) and example.org/non-existant-url (Sb)
#
csarven Two statements. The first will verify, and the second one will fail. If I understood your correctly.
#
ben_thatmustbeme yes
#
ben_thatmustbeme but only 1 request, to the endpoint since i omit target
#
csarven But, here is how the second one could pass:
#
ben_thatmustbeme what is the return from the endpoint?
#
csarven Can you clarify? I consider only one statement to be shipped per POST.
#
csarven re: B likes Sa, we are okay with this right? This is one statement sent in a POST. That will/should verify (given that example.org/post/1 exists and that the target welcomes B, .. interested in 'like' type of mentions, etc etc)
#
csarven The endpoint just says okay thanks for the POST. Cya later.
#
ben_thatmustbeme csarven: i'm trying to get at the fact that without target, there are multiple statements that are potentially shipped per POST
#
csarven An HTTP 202 if that's what you are asking.
#
csarven No, I never said anything about multiple statements (potentially or otherwise) shipped per POST.
#
ben_thatmustbeme so if i created a single post that likes multiple URLs, but only send source, what is the statment?
#
csarven Whatever you want it to be.
#
csarven "but only send source"?
#
csarven POhhhh
#
csarven Ok
#
ben_thatmustbeme yes, the "only send source" was what i meant
#
ben_thatmustbeme s/what i meant/was the key there
#
csarven So, if you just send `B`, the receiver can do whatever, really. You see, the receiver is already equipped with sufficient control to do whatever they want because it is coming from B. It doesn't even need to go out and check B if it doesn't want to.
#
csarven Same type of decision is made for the property. If your endpoint only supports 'like-of' and 'repost-of', but not 'bookmark-of', you can dismiss the rest.
#
csarven Same for the target, if you only want mentions to some of your URLs, you can ignore it.
#
ben_thatmustbeme yes, but you can always fetch the source and determine repost-of / like-of / etc from the content
#
csarven At this point, it is entirely up to you what to look for at source, if at all.
#
csarven Sure, I'm just saying that, if you are only interested in people liking or reposting your stuff, and that's what you want to show in your articles later on, then you can ignore any mentions being made to your endpoint that's something other than those e.g., bookmark-of
#
csarven And you don't even need to check the source for that, because you know the property.
#
csarven This is no different than what you would do to the target.
#
csarven On my site for example, I don't care about mentions made to my homepage because I'm not displaying them in the end.
#
csarven For the other articles, sure.
#
ben_thatmustbeme thats a different issue
#
ben_thatmustbeme thats just when you decide to dismiss or not
#
ben_thatmustbeme this is about being able to determine what the claim is
#
csarven Well, it is a wildcard right?
#
csarven source:B, property=*, target=*
#
ben_thatmustbeme yes, but wildcard will match multiple
#
csarven *May* match multiple, yes.
#
ben_thatmustbeme s/will/may/
#
ben_thatmustbeme so its possibly multiple claims in one POST
#
csarven No!
#
csarven Multiple *statements* may be found at source during the verification step.
#
csarven The claims doesn't say anything other than, source just brought up something to your attention Mr. Endpoint.
#
csarven however you want to anthropomorphize that :)
#
csarven Technically it doesn't say anything about the property or target.
#
ben_thatmustbeme ah okay, mis-understood your terminology there
#
csarven With source and target, you can discover multiple statements at source
#
csarven With source and property, you can discover multiple statements at source
#
csarven With source and property and target, you'll discover a single statement at source (the other would be a duplicate)
#
csarven I mean, if you see the same statement again, obviously it is just a duplicate.
#
csarven B like-of Sa, B in-reply-to Sa <--- Multiple
#
ben_thatmustbeme thats true, i didn't think about that case
#
aaronpk That finally makes sense. Why didn't you say that at the beginning? ;-)
#
csarven Sorry, perhaps I didn't understand the question.
#
aaronpk The question was "why is property needed"
#
ben_thatmustbeme that certainly makes sense
#
csarven I think I used the term 'precision' a number of times? :)
#
ben_thatmustbeme but thats one side of it, adding perperty
#
ben_thatmustbeme i'm more concerned about making target optional
#
aaronpk these have always been two separate issues, don't confuse them
#
ben_thatmustbeme yes, i know, thats why we created the other
#
csarven See the table at http://csarven.ca/webmention#webmention-posts . What's not checkmarked is a wildcard.
#
ben_thatmustbeme so source is required, property is option, and target is required sometimes and optional other times
#
rhiaro I have some posts that are both a like-of and a repost-of the same link. I don't display them properly because my templates currently can only handle one such property, but when I do, when I send a mention to the target, the target is going to have to decide whether it wants the like-of or the repost-of or both
#
csarven Yea, source is required :) If no source, what would one do?
#
rhiaro (my site currently displays the first one it finds in the store)
#
rhiaro (actually no I think like takes priority for no particular reason)
#
rhiaro But I decided, why *can't* l like and repost a post at the same time? Jury is still out on that, maybe it's a terrible idea.
#
aaronpk my endpoint also looks for specific properties in an arbitrary order
#
rhiaro But with required property, I'd have to send two, precise mentions for the same posts
#
rhiaro Which is fine
#
rhiaro Less guesswork involved
#
rhiaro For everyone
#
ben_thatmustbeme i had been working on getting mine to recognize both i don't know it ever worked or not
#
ben_thatmustbeme as no one tried it that i know of
bengo joined the channel
#
ben_thatmustbeme csarven: does it really make sense to tell people target is only required under certain conditions though? thats why it has been generally required.
#
csarven ben_thatmustbeme For pure functionality, only source is required. The rest can be dealt with at the receiver's discretion. I'm just saying that if all are provided (and I think that we should strongly encourage this), it makes both receivers and senders life easier. It cuts down on all the heuristics you might be doing in your code to figure out 'oh what do i do in this case to see if the claim can be verified.. or do I actually want to deal with this? hmm,
#
csarven why did i come all this way to find out that i didn't want to handle that scenario.....'
#
csarven ben_thatmustbeme Sure, that would be based on implementation types.
#
csarven But it is certainly not something you want to generalize or assume that everyone will be covering those types.
#
ben_thatmustbeme well, you can always decide on a generic type when property is missing (default to a "Mention") but you can't always figure out what the target is if its not provided
#
csarven rhiaro aaronpk I also look for specific properties b/c I have some equivalences for them. If I don't find one of those, I just catch and default them to 'in-reply-to' (provided that everything else is okay)
#
ben_thatmustbeme which is the redirect situation
#
rhiaro Yeah, when I get mentions from documents that aren't marked up at all, I have a 'mention_of' relation that I store, and they appear as replies with a little link-chain icon. That's the fallback.
#
csarven ben_thatmustbeme You can. If you one or more statements matching the claimed source and property, you might for instance check the target for http://ben.thatmustbe.me/* or only for http://ben.thatmustbe.me/foo or whatever you want.
#
csarven ben_thatmustbeme re: defaulting to mention, I talked about 'webmention' being a super property given the context that we are well (uhhhh) dealing with webmentions: https://github.com/w3c-social/webmention/issues/1#issuecomment-160293030
#
csarven We know it is a mention of some sort obviously, but can we know more?
#
aaronpk all mine start out as a "mention" and then get upgraded to reply, like, etc
#
csarven I can't think of a reason why the sender would not want to provide the property parameter to the endpoint! It helps them both.
#
csarven aaronpk Right, same as what I said.. but the wording was the other way around. I have a switch statement basically
#
csarven I just happen to choose in-reply-to for the default.
#
rhiaro I reply to my own posts a lot, and thread my own replies by sending myself webmentions, same as if replies came in from outside. If I didn't specify target, I'd find a lot of links to my own domain on every post (in side bar etc) and would need to implement logic to work through and disregard the ones that aren't actually posts. Which is a massive pain, but not insurmountable. Though, if I had check ten thousand links to make sure none of them were mine, my
#
rhiaro server would probably fall over.. but again, I can choose to stop processing if I don't find it after checking ten links I guess.
#
ben_thatmustbeme csarven: but they might not be in the form of https://ben.thatmustbe.me/ they could be http://btmb.me or bit.ly or t.co/
#
csarven rhiaro Right, and why would you not want to provide target.
#
ben_thatmustbeme indeed, why would you EVER not want to provide target
#
csarven ben_thatmustbeme See the earlier discussion on what could be verified. =)
#
rhiaro Just saying if there's no target, the server should take reasonable precautions to avoid being DDoSed. But it doesn't make the situation impossible.
#
rhiaro s/should/can and should
#
csarven If the endpoint receives the bit.ly in the target parameter, it will work just fine.
#
ben_thatmustbeme s/being DDoSed/being an agent of a DDoS/
#
csarven rhiaro Sure, all based on what the implementation/server wants to do.
#
csarven People are doing that already any way!
#
rhiaro Right
#
csarven Each of you have your own heuristics and decision making on how you verify already!
#
csarven rhiaro might follow 5 redirects, aaronpk might do 20, I might do 1, ben_thatmustbeme might do 0. Whatever.
#
rhiaro Well, the spec says follow 'all' redirects doesn't it?
#
csarven hehe
#
aaronpk I'm pretty sure it's never a good idea to omit target, can we all agree to stop pushing for that?
#
csarven If it does, that's naive
#
rhiaro I don't think anyone really wants to omit target :)
#
csarven I don't think anyone was pushing that idea.
#
csarven :)
#
rhiaro But this is a useful discussion anyway
#
aaronpk can we stop talking about it then?
#
aaronpk i'd rather talk about property specifically
#
csarven 911, what's your problem?
#
aaronpk it just feels like we're wasting cycles talking about dropping property when nobody is actually advocating for that
#
aaronpk s/property/target
#
ben_thatmustbeme indeed
#
ben_thatmustbeme i think target should be required in all cases, and property certainly makes sense, but is optional
#
csarven aaronpk Let me say again that, yes, things will function just fine without the property too. But, if we are talking about it at that level, we need to acknowledge that things will function fine without target too. That may have been the confusion on thinking that we want to allow target being optional. Yes, it can be, but we would rather not.
#
csarven Argh..
#
rhiaro I think this whole target thought experiment was to work out if the reasons for target being required are equivalent to property being required
#
csarven Yes!
#
ben_thatmustbeme things will function fine without property, but it is an iterative improvement, SOME things will function fine without target, others will not
#
rhiaro aka if property is optional, equivalent is target is optional
#
ben_thatmustbeme thats the distinction
#
csarven <insert URL to the Robustness principle here>
#
csarven People are going to do whatever they want.. regardless of what the spec says.
#
rhiaro I would hope that bringing the spec to the WG was to work on useful improvements, coming from other perspectives and other implementation experiences
#
csarven So, might as well say that hey this is a good idea, do that.
#
ben_thatmustbeme sure, but thats an argument for not having any specs at all
#
csarven If they happen to do less, you are going to deal with it any way.
#
rhiaro hides because she doesn't even have her own webmention receiving working fully yet
#
aaronpk https://github.com/w3c-social/webmention/issues/19
#
rhiaro I try to look at these ideas from completely outside perspective sometimes. If a developer comes to the spec and it says source is this, target is this, property is the relationship between them from your chose vocab but if you don't have an explicit relationship you can default to "webmention"(/whatever) ... the person intending to implement is going to be like 'okay!' and not actually stress too much about the property inclusion
#
rhiaro Removing *all* baggage
#
rhiaro If they have some semantic markup already (schema, microformats, the next big thing) they'll undersatnd and shove that in the property
#
rhiaro For people who are super keen on semantic markup, they're going to really enjoy shoving that in the property
#
rhiaro For people who don't know what semantic markup is, they'll use the default in the spec and go on with their lives... but maybe will be encouraged to learn about semantic markup
#
csarven Having the property parameter is an excellent practice, why would we not want to encourage that? What's the down side?
#
rhiaro imagines developers with 0 baggage.. maybe delusional?
#
csarven Let me be more clear, it makes no difference if you are using mf2, RDFa, or doopiedoodah. They work exactly the same way.
#
csarven Tomato, tomato.
#
ben_thatmustbeme just read those both the same in his head :P
#
csarven How about 'potato, potato'?
#
ben_thatmustbeme hehe
#
ben_thatmustbeme I don't see a down side to suggesting people use it, its certainly an improvement
#
ben_thatmustbeme other than maybe having to know what vocab to use, but its pretty much the same issue when you fetch the source anyway
#
rhiaro right!
#
csarven I do this hack:
#
csarven I check if property is available, if it is, I see if it is a URL or prefixed name, if it is, I go with the idea that the source is in RDFa.
#
csarven Otherwise, I consider it being a term, and it so, I go with the idea that it is probably a mf2/IWC term
#
csarven or at least I check for the "common" ones I like to deal with.
#
rhiaro I could imagine caching how people I know markup their sites, and checking that to decide what property to send to them (assuming I use both rdfa and mf2)
#
csarven But since the rel value can be anything, it is entirely up to my internal logic to figure out how I want to deal with it for both verification, as well as the UI
#
rhiaro (and assuming that how people markup their sites is an indication of what they'd be willing to parse from me)
#
csarven rhiaro Good idea! But I think it is not so much about what's on that site but rather what may be at individual URL.
#
csarven So, you never really know until you get there. It coul dhave both mf2/RDFa/x/y/z...
#
csarven The property may give a hint at it. Which is what I'm doing.
jaywink joined the channel
#
rhiaro yeah
bblfish joined the channel
#
wilkie fd~.
#
wilkie sorry :)
#
ben_thatmustbeme wilkie: no, thats inexcusable :P
#
wilkie haha aw
bengo, shevski and bblfish joined the channel
#
cwebber_remote ben_thatmustbeme: submit to the github tracker
cwebber2, bblfish and jasnell joined the channel