See also: IRC log
<cwebber> o/
<Loqi> meeting time
<Loqi> Countdown set by ben_thatmustbeme on 2017-04-18 at 2:27pm UTC
<cwebber> agenda is at https://www.w3.org/wiki/Socialwg/2017-04-18
<cwebber> ajordan, np
<rhiaro> o/
<scribe> scribenick: aaronpk
<KevinMarks> May be irc only
<eprodrom> https://www.w3.org/wiki/Socialwg/2017-04-11-minutes
<eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-04-11-minutes as minutes for previous telecon
<cwebber> +1
<sandro> +1
<rhiaro> +1
<eprodrom> +1
<aaronpk> +1
RESOLUTION: Accept https://www.w3.org/wiki/Socialwg/2017-04-11-minutes as minutes for previous telecon
cwebber: a new tutorial for activitypub, i threw it together after sketching it out on paper. i was thinking about adding something like this to the introduction to the activitypub document
eprodrom: i need an update on why
we have a meeting today, since we had a scheduled meeting next
week
... i understand there is a crucial deadline for
activitypub?
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
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.
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.
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
<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: "evan@e14n.com"
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
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: cwebber, aaronpk, rhiaro, sandro, ajordan, eprodrom, KevinMarks, csarven, ben_thatmustbeme Present: cwebber aaronpk rhiaro sandro ajordan eprodrom KevinMarks csarven ben_thatmustbeme Found ScribeNick: aaronpk Inferring Scribes: aaronpk Agenda: https://www.w3.org/wiki/Socialwg/2017-04-18 Found Date: 18 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/18-social-minutes.html People with action items:[End of scribe.perl diagnostic output]