Social Web Working Group Teleconference

18 Apr 2017

Attendees

Present: cwebber, aaronpk, rhiaro, sandro, ajordan, eprodrom, KevinMarks, csarven, ben_thatmustbeme
Regrets Chair: eprodrom
Scribe: aaronpk

sandro: i wouldn't characterize it as quite that urgent. but it seems like activity is picking up on activitypub and we have a lot to do.
... i sent an email that there's a process loophole that gives us more time than we thought. we just have to get to PR by the charter, not REC by the charter.
... so we have until May 13th to make any normative changes if we really push the line.
... but given we have all this external interest, it seems like keeping the discussion going quickly is good. like if it turns out mastodon says you really need to make this change then we need to know this as soon as possible

eprodrom: the thing i want to avoid is doing a deep dive on the tutorial for examle and then we have 5 minutes to do the important things
... do we have a vote we need to take by the end of the day?

cwebber: no

sandro: lets' focus on the things that are going to get the community together on an interoperable implementation

eprodrom: so we're going to be going through some of the issues on activitypub and make sure we move things forward

ActivityPub

cwebber: we had an open item to include an introduction with clear diagrams and examples. i had sketched out on paper how to make it clear what's happening with the inbox and outbox. i turned that into the ascii art tutorial.
... a lot of people responded positively especially in the ostatus sphere
... i'd encourage people to read it and see what they think. one of the pieces of feedback we got before was "oh this seems like a lot" but now with the tutorial it's more "this is pretty straightforward"

eprodrom: i've seen tutorials as separate documents. is it normal to have a tutorial in a spec document?

sandro: if it goes through every feature then it makes sense separate, but this seems more like a hello world so it's fine in the spec

eprodrom: the only thing i'm worried about putting such a large text in the spec is it asks for some definitions, but that's probably okay. getting the text right is non-normative so we don't have to worry about getting it perfect the first time out.

Implementation Updates

cwebber: there's been a lot of discussion. the most interesting is probably with mastodon.
... there's been a lot of questions, the leader seems supportive of exploring things. people seem to want activitypub because they want a better private distribution support.
... evanminto is making progress on it. we've got open issues elsewhere like diaspora, but that seems more like conversation right now. tho one person seems to think diaspora might move forward with it.
... other projects like postActiv and gnusocial are considering it. postActiv has someone assigned to it.
... for pump.io, they plan to do a branch soon as a feature branch but won't merge it until PR

<ajordan> so for pump.io

<ajordan> we will probably ship it preffed off July 1

<eprodrom> ajordan: can we get an implementation report and test results sooner?

<ajordan> eprodrom: absolutely

<eprodrom> +1

<eprodrom> Implementation reports are what get us out the door

<ajordan> I'm planning on submitting an implementation report as soon as the code is written, which should be this week or the next week

<eprodrom> https://www.w3.org/wiki/Socialwg/ActivityPub_network

eprodrom: there is a page which links to all the known open issues on different projects
... we are talking about getting implmeentations of server-to-server and client-to-server as separate things. mastodon was only interested in server-to-server for example.
... sounds like a lot of activity. pushing it through from open issues to online implementations will be the big move over the next few weeks.

test suite

cwebber: i know i said i'd have it earlier. it took me a while toget the interface stuff done, and have some initial test done, but i need to document it so you don't go insane looking at the code
... i'm feeling very optimistic about it. by next week we should have a much more exciting update.
... evan would you want to schedule time this week to do an overview of the code? or just email

eprodrom: yeah i'm happy to sit down and talk about it
... i volunteered to help out with the test code, if anyone else wants to help then you're welcome to come otherwise it's not a helpful meeting to be at

activitypub issues

<ajordan> which meeting? next WG meeting?

cwebber: i put the issues that need more heavy discussion first

<cwebber> https://github.com/w3c/activitypub/issues/185

cwebber: there are two sides for this. pump.io has this and we somehow omitted it.
... every object can be favorited and liked and shared around, and you want to track that.
... pump.io has two names for this, "likes" and "shares"
... and we don't have those
... hilariously we've clobbered the namespace. we use "likes" to be what pump.io calls "favorites"
... i think what we need to do is add these two properties "shares" and "likes" and possibly rename the "actors" collection to "favorites" to avoid a naming collision

<ajordan> I believe favorites and likes are the same thing in pump.io? eprodrom?

eprodrom: that seems reasonable

<eprodrom> {totalItems: 30, url: "..."}

eprodrom: this would be a valid collection

<eprodrom> {type: "Collection", totalItems: 30, ...}

eprodrom: there's a way to link to the collection with the number and url for the collection
... the big thing is getting the number out
... there's synchronization issues when you include numbers like this across boundaries, but i think that's a reasonable mechanism

cwebber: i think one advantage of using the collection is it could be someone included just the number but hopefully they included all the objects as well
... you can't really trust a number you get across a federated boundary anyway
... i think it's useful to have it be a number and also a collection

sandro: i was worried about the security there. if you get all the objects, you can dereference as many as you like, and see that they check out. if you get a number, you can't verify it, an attractive nuicance.

cwebber: that's why having it be a collection with a number as a cache is the best route

sandro: what would you do with the number? if you display it, then you've propagated the attractive nuisance to the user.

cwebber: all the federated implementations have that problem anyway. you either trust that number or you don't

sandro: we should at least say something in the security considerations.
... is there also some sort of security checks you should or must do before passing the number on?

cwebber: i'm hesitant to suggest that because i don't think we'd get that completely right

rhiaro: i wanted to comment on renaming the collection
... favorites bugs me because there are two spellings of it
... could we call it something more precise like "things liked"?

cwebber: we could call it 'liked' instead of 'likes'

eprodrom: 'likes' is a link to a collection of objects this actor has liked

cwebber: okay i think that will be a normative change so we've already entered that territory.

<rhiaro> yep

cwebber: given the comments sandro has made then we should just do normative changes instead of trying to work around that

<cwebber> https://github.com/w3c/activitypub/issues/192

cwebber: i wanted amy's feedback on this. we mention that you can discover an actor's profile at one point in the exit criteria and then it's never mentioned again.
... shoudl we allow the profile to be used as an actor. it allows people to have multiple identities.

Zakim: who is on the call?

Zakim: who is here?

<eprodrom> Please mute you mic

<cwebber> muted

<eprodrom> Muted

<csarven> Muted when joined

<ajordan> already muted

<aaronpk> muted

<eprodrom> Thank you

<rhiaro> always muted when I'm not talking

<eprodrom> KevinMarks: ?

<ben_thatmustbeme> oops

<csarven> ^^^ that guy

<ajordan> lol

cwebber: it looks like amy made a suggestion on this issue already
... that would allow people to create sub-identities for themselves. does that seem like ar easonable thing to add?
... does that mean the new profiles would have their own inbox and outbox?

rhiaro: i feel like making it clear that it's allow, then let the implementations decide how it's allowed
... i think all we need for activitypub is to make it clear you can use it

eprodrom: this feels like a lot of complication without a lot of payoff
... having multiple profiles with multiple endpoints, i don't see a lot of reason to not just use multiple accounts in that case

<cwebber> cwebber-

eprodrom: it seems like we're using it because it got into activitystreams and i'm not a fan of how it got there either. so unless there's a clear use case we need this then i feel very -1 on this

cwebber: i'm okay with it existing as long as we treat it exactly like an actor object anyway

<rhiaro> right

cwebber: but i agree if we start doing the thing where the implementation needs to traverse and find the relationship between it and the actor then it will add more complexity
... i'm okay with including it but i dont feel strongly about it

<rhiaro> Talkinga bout different personas was the use case. Not something I think should be in the spec.

<rhiaro> I don't want to add ANY of this stuff to the spec.

eprodrom: once we're talking about different identities, like evan as w3c chair, or evan as fuzzy.io ceo, or evan as father of children, those are all different aspects to my personality. i think diaspora calls that aspects event.
... what we do for that is lists in pump.io and direct things to different follower lists

<ajordan> ajordan-

cwebber: i might have a quick way to resolve this.

<rhiaro> but Profile isn't listed in AS2 as an actor type

<rhiaro> just under objects

cwebber: to drop all the language about the profile object. since activitypub says these are generally activitystreams actor types then it's expected you're probably producing one of the existing ones. if someone wants to go crazy they can.

<rhiaro> q

<Zakim> rhiaro, you wanted to comment on rename of actor's likes and to and to

rhiaro: i said it was an implementation detail, so we leave it open for implementations but we don't add anything to the spec
... that's whyu i suggested adding the "or a profile object" because profiles aren't actors
... but i wouldn't try to figure out implemnentation details in the spec

eprodrom: i feel like this is important but complex. if an implementation has a Profile as one of the things that has inbox/outbox etc then that's up to the implementation

ajordan: since we're talking about complexity, it's worth noting that getting the privacy right on this is difficult.

<cwebber> I agree re: privacy w/ these use cases

eprodrom: adding a privacy note to the security considerations is probably important.

sandro: so far this has been too loosey-goosey to know what the argument is. so maybe we can look at this as what will the test suite have different based on the resolution of this

<ajordan> so we talkd earlier about treating Profiles as Actors so they didn't share inboxes or anything, but assuming that wasn't the case there's this issue of identity correlation based on inbox URLs

cwebber: i don't think the test suite would do anything differently

<ajordan> no nono

eprodrom: let's focus on profiles as actors
... it seems like we could add that to the test suite
... have a Profile that you can follow as if it were an Actor

cwebber: are people fine with adding the Profile object then?
... my suggestion for how to close this out is to just not mention it and it wouldn't specifically be blocked it would just be not mentioned
... would people prefer to include it as an option? or just be never mentioned?

sandro: we need test cases either way
... otherwise we don't have interoperability

cwebber: i suggest we include it and add a test case
... adopting the language amy added, and mentioning it in the security section, and adding it as a test case

<eprodrom> PROPOSED: Accept rhiaro's edit to close https://github.com/w3c/activitypub/issues/192

<cwebber> +1

<eprodrom> +1

<rhiaro> +1

<ajordan> +1

<sandro> +1 with new test case

<ben_thatmustbeme> +1 sounds reasonable

RESOLUTION: Accept rhiaro's edit to close https://github.com/w3c/activitypub/issues/192

<cwebber> https://github.com/w3c/activitypub/issues/198

<cwebber> https://github.com/w3c/activitypub/issues/185

cwebber: actually if we only have 10 minutes let's go back to the previous issue
... we never ended up saying what the "share" object was
... we used to have a "share" object in AS2 but it was dropped
... now we have an "announce" object which is ambiguous and doesn't mean "share"

<cwebber> https://github.com/w3c/activitypub/issues/186

eprodrom: this is sharing

cwebber: we're going to agree that this is sharing and i'll add the side effects to the document then?

<cwebber> https://github.com/w3c/activitypub/issues/194

cwebber: one challenging thing is the webfinger side of things. this came up from mastodon
... how do people migrate from using webfinger identity into a https identifiers rather than webfinger
... i have a suggestion for how to do this

<cwebber> https://github.com/tootsuite/mastodon/issues/1557#issuecomment-294529696

cwebber: in this mastodon thread, sandro pointed out that we can use the acct uri, it could create problems by using both a mixture of https and acct URIs
... so my suggestion is to add an informative section as follows
... you'd end up saying okay if you have a post that uses a webfinger ID in the UI somewhere, you look up the webfinger ID and look up their https address to send it via activitypub
... the other thing is you have an actor's profile, how do you look up what the webfinger ID is. my suggestion is you take the "preferred username" slot and append @ the domain name
... however there's a possibly problem. there's the possibility that preferredusername is not unique
... eprodrom do you have comments on this?

<eprodrom> webfinger: "[email protected]"

eprodrom: it seems to me like a property "webfinger" would solve the problem
... i agree that doing webfinger lookup to get the activitypub ID is good, we may need to define a link type to make that happen
... i'm not sure this is core to activitypub though, this might need to be an extension

cwebber: i think your suggestion of adding a webfinger property is good especially since this is coming up now

eprodrom: my suggestion is to make it an extension
... a bridge between webfinger and actiivtypub. it's only important right now because there are people using webfinger but that might drop off

cwebber: i don't know what to say to the mastodon people then, if we don't have any extension process now.

sandro: i think it would be great to see how lightweight we can make the extension process then

eprodrom: could it be a wiki page?

<KevinMarks> What is the webfinger use case? Give me the profile url for $username at $domain?

eprodrom: anyone doing a new implementation of activitypub would look at that section and say why do i need to support webfinger?

<ajordan> KevinMarks: basically

<ajordan> we're discussing transitioning legacy Webfinger systems

eprodrom: i think just because mastodon wants it now, isn't a good reason to include it for the people reading this 10 years from now

cwebber: i guess we're out of time so iw on't bring up any more issues
... the spec didn't permit federation without client to server but last week we talked about allowing that

<KevinMarks> I think there is a much simpler way to do that.

eprodrom: do we need fto have a discussion about that

cwebber: there's nothing that jumps out to me as long as people are okay with ......

eprodrom: i'm going to ask to extend for 10 minutes

<sandro> +1 extending whatever's useful

eprodrom: i don't udnerstand your question. do you want us to look through the list and see if anything else needs to be addressed today?

cwebber: i'm just getting confused by process i guess

<eprodrom> PROPOSED: Extend meeting by 30 minutes

<sandro> +1

<cwebber> +1

<ajordan> +1

<wilkie> do we have a wiki for activity pub for cwebber and my own notes on the webfinger/identity legacy stuff? because it should go there, not in the spec itself, I'd think

<rhiaro> +1

<eprodrom> +1

<sandro> wilkie, sure, the group wiki is the w3c wiki which is fine

RESOLUTION: Extend meeting by 30 minutes

<eprodrom> wilkie: agreed!

<KevinMarks> +1 for Wiki about webfinger replacement

sandro: if it's going to affect the test suite, change implementations, or make someone mad, then bring it to the group. otherwise you don't need to.

<cwebber> https://github.com/w3c/activitypub/issues/189

cwebber: inboxes. this is a conversation that amy and i went through already.

<KevinMarks> Wilkie: I have some ideas on replacing webfinger to contribute as well.

rhiaro: this is basically a clarification but turns out to be a normative clarification

<eprodrom> https://github.com/w3c/activitypub/issues/189#issuecomment-294332336

<wilkie> we don't need to *replace* webfinger, I mean... that's a little bit extreme

rhiaro: whenever we say "inboxes must accept post request" we caveat that with "federated implementations" because some implementations may not accept post requsts and still be valid

<eprodrom> PROPOSED: close issue 189 by adding text from https://github.com/w3c/activitypub/issues/189#issuecomment-294332336

<KevinMarks> Implementing webmention is extreme, I think we can do something much simpler.

<cwebber> +1

<ajordan> +1

<eprodrom> +1

<wilkie> +1

<rhiaro> +1

<KevinMarks> (I meant replace in the mastodon codebase/ostatus stack)

RESOLUTION: close issue 189 by adding text from https://github.com/w3c/activitypub/issues/189#issuecomment-294332336

<sandro> +1

<cwebber> https://github.com/w3c/activitypub/issues/191

cwebber: we have endpoints for OAuth authorize, but never added an endpoint for getting an access token
... this person suggested adding it to the endpoint section
... i haven't thought what the best name for it is

sandro: everyone has to do this? or only if you're doing oauth?

cwebber: only if you're doing oauth
... it doesn't make anyone reverse anything they already did.

eprodrom: i'd like to push this to the end of the call

<eprodrom> PROPOSED: close https://github.com/w3c/activitypub/issues/191 by adding properties with names from OAuth2 spec and revising current oauthClientAuthorize property name

<cwebber> +1

<ajordan> +1

<eprodrom> +1

<sandro> +1

<aaronpk> +1

RESOLUTION: close https://github.com/w3c/activitypub/issues/191 by adding properties with names from OAuth2 spec and revising current oauthClientAuthorize property name

<rhiaro> +1

<cwebber> https://github.com/w3c/activitypub/issues/198

cwebber: there's some ambiguity around what ambiguity means. it sounds fine but it makes it sound like the only way to do delivery is HTTP post
... but there's an obvious exception which is that you don't have to do this if you're on the same server
... so i don't want to make it sound like iuf you're on the same server you have to do a POST to yourself

<eprodrom> https://github.com/w3c/activitypub/issues/198#issuecomment-294855618

eprodrom: amy gave some proposed text in a comment

<eprodrom> PROPOSED: close issue 198 by including text from https://github.com/w3c/activitypub/issues/198#issuecomment-294855618

<eprodrom> +1

<rhiaro> +1

<ajordan> +1

<sandro> +1

<cwebber> +1

<wilkie> +1

RESOLUTION: close issue 198 by including text from https://github.com/w3c/activitypub/issues/198#issuecomment-294855618

<cwebber> https://github.com/w3c/activitypub/issues/188

cwebber: this person has experience around distributed database things. they suggested including revision IDs to avoid accidentally clobbering things

eprodrom: you know there's an updated timestamp on activities, so the ID plus the updated timestamp should be unique enough to say what revision it is
... that's what we used for pump.io

aaronpk-

ajordan: using the timestamp assumes everyone's clock is reasonably synchronized

eprodrom: i don't think it's as much as a big deal being synchronized as it is having your clock stay current.
... as long as i'm talking to you, we go by your clock.

<KevinMarks> This is how Google's protocol ended up mandating atomic clocks

sandro: is this supposed to be aligned in any way with HTTP? if you're doing a GET or PUT then HTTP has last-modified and etags which are all for revision control
... it would be nice if this is using URIs for things then to just use those

eprodrom: there isn't really anything keeping it from being aligned. i think "update" ends up being the same as "last-modified" header. etag would map to this revision ID idea.

<cwebber> https://github.com/w3c/activitypub/issues/155

cwebber: one reason to explore this in future efforts... as for adding anything new, we should wait for the future

sandro: one simple thing we could do is to say that the time counter MUST increment. you try to make it an accurate time, but you at least never use the same timestamp twice.

<KevinMarks> https://xoxo.zone/@KevinMarks/71212

<Loqi> [Kevin Marks] @maiyannah can you just use etag/lastmodified for this? if the etag is a hash of the profile then it should do what you want.

<KevinMarks> So fuzz leapseconds

<cwebber> https://github.com/w3c/activitypub/issues/196

cwebber: if you imagine you're using any of these social networks, you might have your stream of posts and a different 1-1 conversation thread with someone
... the commenter said they want the private message flagged differently and not just the things streaming through the inbox
... there were a number of directions to go with this, a "priority" flag property

<wilkie> I don't think you need to spec how the revision or tag is generated, just that it may be used to reject updates

cwebber: i have a hard time thinking that we're going to make any sensible change to the spec within the timeframe we have
... but we're seeing that they're insistent we hvae some sort of flag, otherwise they will use an extension
... my feeling is to do this as an extension

<wilkie> I don't understand the distinction they want and how audience tracking doesn't just solve this

<wilkie> what is the difference between a message sent to only you and an important message sent to only you

<rhiaro> I don't really understand why clients can't figure this out from the addressing and any other context they want to take into account

<rhiaro> and different clients might handle it differently which is fine..

<wilkie> exactly

<wilkie> clients will either ignore some measure of priority or publishers will abuse it

ajordan: it's not clear when you should put individual people in the "to" field, so maybe that's where theconfusion is coming from

<rhiaro> "Clients are responsible for addressing new Activites appropriately. To some extent, this is dependent upon the particular client implementation, but clients must be aware that the server will only forward new Activities to addressees in the to, bto, cc, bcc, and audience fields."

ajordan: if you're trying to implement a feature that says this is a direct message, then you can say it's a direct message if there is only you in the "to" field

<rhiaro> it actually says you must dereference addressed collections and individually address everything doesn't it? so maybe that's the problem..

cwebber: one more thought on this. my impression is that one thing pump.io has that activitypub doesn't have is the differentiation between a major feed and minor feed.
... it coudl be reasonable to say to the inbox give me all the stuff that's directed just to me

<wilkie> rhiaro: ah typo there ... apparently "Activites" is in the document twice

eprodrom: we're over our overtime

rhiaro: there's a section about client addressing in the spec. whenever you find obects attached to an activity you shoudl follow these links and dereference the collections and put them in the "to" field

<rhiaro> http://w3c.github.io/activitypub/#client-to-server-interactions

rhiaro: maybe we can't solve this now and we need to think about the wording some more

cwebber: so i should remove the "postponed" flag since it seems like there is more conversation to be had

eprodrom: let's wrap up the meeting since we're already over time

<eprodrom> trackbot: end meeting

Summary of Action Items

Summary of Resolutions

Accept https://www.w3.org/wiki/Socialwg/2017-04-11-minutes as minutes for previous telecon
Accept rhiaro's edit to close https://github.com/w3c/activitypub/issues/192
Extend meeting by 30 minutes
close issue 189 by adding text from https://github.com/w3c/activitypub/issues/189#issuecomment-294332336
close https://github.com/w3c/activitypub/issues/191 by adding properties with names from OAuth2 spec and revising current oauthClientAuthorize property name
close issue 198 by including text from https://github.com/w3c/activitypub/issues/198#issuecomment-294855618

[End of minutes]

Socialwg/2017-04-18-minutes

Social Web Working Group Teleconference

18 Apr 2017

Attendees

Contents

last week's minutes

ActivityPub

why are we here

ActivityPub

Implementation Updates

test suite

activitypub issues

Summary of Action Items

Summary of Resolutions