ben_thatmustbemeHaving a standard is good, eme makes sense in empowering competitors to Netflix for example. I do believe that's a good thing. But timbl just pissed on the while idea of rough consensus being a core principle of w3c. The statement was made that the proponents of eme were unwilling to compromise so he approved it.... Which now sets precedent for everyone to be extremely stubborn because you can eventually just get whatever you want
cwebber(I suggested it as an option as opposed to saying "you have to do this" because you really don't have to... I just think it'll be less painful if you do :))
Gargron" Okay, but what is better? If a different platform wants to implement emojis, but not "fortune cookies", wouldn't it be better if they only needed to include emoji-specific context, rather than the "general mastodon" context?"
cwebberGargron: vocabulary namespace is "where the terms go" as in terms of "this specific uri really means this one specific thing". so "http://joinmastodon.org/ns/#Emoji" in this example would mean Emoji as a specific *concept*
csarvenGargon, if you take the ns approach, I suggest defining the terms you'd like to use at a neutral-enough location, and keep it public for input. Off the top of my head, https://w3id.org/ might work for your needs.
csarvenUsing mastodon in the domain is in some ways signals that it is mastodon specific. That is of course fine in and of itself but may deter its use from non mastodon implementations to reuse.
csarvenI'm a bit ignorant on what's going on and half paying attention to the emoji/mastodon discussion here :) Keep that in mind.. So, are mastodon emojis part of the content, like any character in the status update, or do they indicate some (re)action either made, to be made or to trigger?
xmpp-social[ajordan] They're both lists of really small problems but there's a lot of them... wasn't sure how you wanted to manage them so I didn't do anything, but I can break them up into multiple issues, etc.
Loqi[AJ Jordan] AJ Jordan AJ Jordan at 2017-09-19T17:03:06Z (As seen today on the SocialWG call) @Christopher Allan Webber: I'm here to clack keyboards and ...
rhiaro... We are far enough along that it's going to be up to us to mess this up. My feeling is we don't need to do more than two during October. Any objectiosn?
rhiarocwebber: I'm going to be at rebooting web of trust on Oct 3rd. I can maybe step away to be at the meeting. I also want to set expectations that I might not have that much to say because I'm representing a client all next week in DC and then I'm at rebooting web of trust, so that's going to take up a bunch of my time
rhiarocwebber: Update on the test suite is that I've been working onit, had an unexpected item pushed onto the queue for it. Since Mastodon has taken the lead and a couple of other implementations are using http signatures be mandatory for server-to-server, I had to implement that
rhiaro... as far as I know every implementation did this. It was just omitted. Something we should add. Not sure if it is considered normative, technically it's a requirement, but it was a bug in the spec
rhiarocwebber: this was the result that we came to because it wasn't clear waht the future direction was. I'm still not going to say that the worl dhas completely ... basically we left two routes, one was oauth2, one was LD signatures and http signatures
rhiaro... it sometimes results in a problem where the top poster in a comments chain gets comments from other servers and people in the thread miss out on messages
tantekTBH all the signatures stuff feels like it needs more incubation to figure out something that works cross-implementations. It's feels like perhaps the biggest interop risk in all of AP. Hoping for the best, but pretty concerned (not raising any objections, just worries).
tantekajordan there's always something to be done. e.g. separating anything related to it into a separate add-on spec that is incubated/matured on its own timeline
rhiaro... or just have section 8 be a pointer to some document maintained by the CG that can refine this going forward and maybe eventually put it into a separate spec
Zakimtantek, you wanted to note there is something very odd with an entire non-normative section that we are depending on for interop of a specific set of features
rhiarotantek: the spec advertises a set of features you get if you interop. We're trying to capture features that are essential noted by folks like mastodon. Good we're listening to our implementors. But not good it's in non-normative text
rhiaro... evan? How do you feel about having pointers to an auth doc written by the CG which is mutable but starts out recommending what's actually in practice?
rhiarocwebber: not just. The forwarding use case .. it's most likely to protect private content becuase that' swhen you can't necessarily look it up. There are two other cases where you still want it
rhiaro... but it sitll is important that i fyou get a post to your inbox that says here's some content, you have to make sure that the contnet really is from that server, and there are two ways to do it
cwebberPROPOSED: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S)
cwebberRESOLVED: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S)
rhiaro... if we wanted to solidify it at some point, some w3c member like mozilla could turn it into a member submission and get it formally archived at w3c
rhiarosandro: there may be some alternative. one alternative is we don't necessarily use the test suite to prove interop. There are other ways, that's the usual one. I can imagine in the s2s thing that it might be more demonstrative to show these two systems federate by running them by hand with people watching
rhiaro... if interop is defined by how two implementations happen to work together, there's no guarnatee we've captured those details in the normative spec
rhiarosandro: if you want to call it the test suite sure, but it wouldn't be doing the same thing as what a test suite would do because it would be driven by hand
rhiarosandro: the standard I just specified is lower than what i was saying before because it doens't invovle puckipedia and mastodon talking to each other
rhiarotantek: you're saying we define interoperation by checking that these two interop. We need a textual description of what should happen when you runt wo implementatiosn against each other. That's a test suite.
rhiaroajordan: if we're going down the prompty path, which seems fine, after we ship a rec I think it would be nice to go back and make that stuff automated, to make new implementations easier
rhiaro... essentially PuSH had only specified sha1 as the only valid hash algorithm. A while ago we had added other algorithsm and sha1 is mostly broken now
rhiaro... but then there was a concern that servers and the hub need a way to negotiate which algorithm to use, which is a rather large new mechanism to add
rhiaro... the current proposal is to drop all the new algorithms from the spec, goign back to the way it was in PuSH and then mention that we may add new algorithms as an extension so we can actually better specify how these algorithms are negotiated
rhiaroaaronpk: julien's comment is that it's not a big deal to use a weak hash beacuse if you're also using https there are a lot of layers to break before you can take advantage of a weak hash
sandro In the future, an extension may be specified allowing subscribers to indicate which algorithms they can use for validation. As of this writing, most hubs sign with SHA-1, despite its known cryptographic weakness, in order to be interoperable with older subscribers.
rhiarotantek: the text sandro put does touch on a security vulnerability, could you include a list item in security & privacy considerations that calls it out explicitly?
rhiarosandro: 124. We have this content negotiation solution we came up with a while ago. Richard the i18n guy pointed out there's language negotiation too
rhiaro... I think the answer is we forgot and should include text saying for either content type negotiation or language negotiation you should be doing the same thing
rhiaro... shall we delegate to aaron to adopt something similar to ben's text and say we'll try to also get richard's approval but I don't think we need to
Loqi[dissolve] Suggested text
For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be...
Loqi[dissolve] Suggested text
For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be...
ben_thatmustbeme Having a standard is good, eme makes sense in empowering competitors to Netflix for example. I do believe that's a good thing. But timbl just pissed on the while idea of rough consensus being a core principle of w3c. The statement was made that the proponents of eme were unwilling to compromise so he approved it.... Which now sets precedent for everyone to be extremely stubborn because you can eventually just get whatever you want
Gargron cwebber: is this correct? https://github.com/tootsuite/mastodon/pull/5004
@JuanitoFatas ActivityPub is the decentralized social networking protocol
https://www.w3.org/TR/activitypub/ #RubyKaigi (twitter.com/_/status/910060668484648960)
@tkawa ActivityPub よさそう #rubykaigi https://www.w3.org/TR/activitypub/ (twitter.com/_/status/910060880162832384)
csarven Gargon, if you take the ns approach, I suggest defining the terms you'd like to use at a neutral-enough location, and keep it public for input. Off the top of my head, https://w3id.org/ might work for your needs.
Loqi Rhiaro made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104461&oldid=104250
RRSAgent logging to http://www.w3.org/2017/09/19-social-irc
ajordan cwebber https://pump.strugee.net/alex/note/pydkkeAFRWyl8QTMCGYojA you're so quotable
rhiaro cwebber: I'm going to be at rebooting web of trust on Oct 3rd. I can maybe step away to be at the meeting. I also want to set expectations that I might not have that much to say because I'm representing a client all next week in DC and then I'm at rebooting web of trust, so that's going to take up a bunch of my time
sandro PROPOSED: Resolved websub #124 with something like https://github.com/w3c/websub/issues/124#issuecomment-330580664 but actual working up to editors