ajordan!tell eprodromou hey while you're here: up to you, but you might want to consider unwatching pump-io/pump.io. that way you'll only get notifications when we need you and I @mention you
ajordaneprodrom: > hey while you're here: up to you, but you might want to consider unwatching pump-io/pump.io. that way you'll only get notifications when we need you and I @mention you
aaronpkcwebber: 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
aaronpk... 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.
aaronpk... 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
aaronpkcwebber: 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.
aaronpk... 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"
aaronpkeprodrom: 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.
aaronpk... 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.
aaronpk... 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.
aaronpk... 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.
aaronpkeprodrom: 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.
aaronpkcwebber: 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
aaronpkeprodrom: 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
aaronpk... 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
aaronpkcwebber: 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
aaronpksandro: 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.
aaronpkcwebber: 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.
aaronpk... 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
aaronpk... 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
aaronpkeprodrom: 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.
aaronpk... 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.
aaronpkeprodrom: 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
aaronpksandro: 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
ajordanso 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
aaronpk... 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
aaronpk... 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
aaronpk... 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
wilkiedo 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
aaronpksandro: 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.
aaronpk... 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
aaronpkcwebber: this person has experience around distributed database things. they suggested including revision IDs to avoid accidentally clobbering things
aaronpkeprodrom: 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
aaronpksandro: 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
aaronpkeprodrom: 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.
aaronpksandro: 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.
aaronpkcwebber: 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
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."
aaronpk... 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
aaronpkcwebber: 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.
aaronpkrhiaro: 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
ajordan<ajordan> hey while you're here: up to you, but you might want to consider unwatching pump-io/pump.io. that way you'll only get notifications when we need you and I @mention you
wilkiedo you think there might be any other things worth noting about using activitypub on top of existing ostatus stuff that might be worth noting in one place
wilkieI'm thinking people will run into "what is the equivalent to X" type of thing and it might be nice to have that on a similar page instead of revisiting "where does this go" later on
ajordanit'll only be relvant for a short period of time anyway; thinking hard about it feels like bkeshedding. we can always make it an "official" extension later
sandro cwebber, do you think you can put together some agenda items for tomorrow, at https://www.w3.org/wiki/Socialwg/2017-04-18 (you can ignore the boilerplate if you want)
Loqi [@csarven] An easy-to-digest #ActivityPub tutorial; ?️ decentralised and federated #SocialWeb ?. See https://www.w3.org/TR/activitypub/ after. #LinkedData ?? QT [@dustyweb] Hi everyone! I wrote a tutorial for ActivityPub, federation spec by the @SocialWebWG. Complete with ascii art! https://raw.githubusercontent.com/w3c/activitypub/gh-pages/activitypub-tutorial.txt
cwebber sandro: yeah I'll do so..
ajordan should https://www.w3.org/wiki/Socialwg#Next_Meeting be updated?
ben_thatmustbeme checks irc-people
RRSAgent logging to http://www.w3.org/2017/04/18-social-irc
KevinMarks Present+
aaronpk found it http://pandoc.amy.gy/