Social Web CG

28 Mar 2018

Attendees

Present: ajordan, aaronpk, saranix, melody, fr33domlover, eprodrom
Regrets
Chair: aaronpk
Scribe: ajordan, aaronpk

eprodrom: so sorry, I don't like hijacking the agenda like this
... so good news is that ajordan and I met over the weekend along with cwebber and we hacked on AP in pump.io
... so we have some of the endpoints working as well as generating AS2 from our database
... as I was looking at our code I realized there's a couple AP props that haven't been added to the context
... I *think* that requires sandro or rhiaro to actually do the push to the W3C servers though

<eprodrom> https://github.com/w3c/activitystreams/issues/465

<Loqi> [evanp] #465 Add "shares" from ActivityPub

aaronpk: I belive that's correct, not sure who else would have access to that

<eprodrom> https://github.com/w3c/activitystreams/issues/464

<Loqi> [evanp] #464 Add "likes" from ActivityPub to context

eprodrom: so I think probably next steps is, I would do this in our GitHub repo and then I'll collaborate with sandro and rhiaro to get it pushed to W3C servers

aaronpk: sorry is this basically a bug with the current context? AP says it should be a thing but it's not in the context?

eprodrom: correct

aaronpk: interesting, sounds like GitHub issues are a good place to track that

eprodrom: the one thing is, I'd like to make sure we do as many of these as possible at once, so I'm gonna do a last pass over AP, add them to the context and ask sandro/rhiaro to do the push

aaronpk: sounds good

eprodrom: do we need to do a vote to approve that process?

aaronpk: I don't think we need to do a vote? we could to document that that's the process we're following
... and people here can provide feedback, as to whether that's a good idea

aaronpk: anyone have thoughts about that? sounds like this is essentially a bugfix so I'm inclined to just let the editors roll with it since it's not creating anything new
... seems very reasonable to me

<ajordan> +1

<aaronpk> +1

<eprodrom> PROPOSAL: add shares, likes, and potentially other properties from ActivityPub to ActivityStreams 2.0 context

<eprodrom> +1

<eprodrom> Cool!

<aaronpk> +1

aaronpk: okay well if anyone else... oh there we go an actual proposal to vote on sure

<ajordan> +1

<melody> +1

eprodrom: okay so if we're okay with it I'm going to take the steps and coordinate with sandro to get it pushed

aaronpk: sounds good and can your report back to IRC as to how that goes?

eprodrom: okay I have to run, I appreciate it and especially fr33domlover I appreciate you letting me agenda jump, I know that's a hassle

fr33domlover: it's okay

aaronpk: thanks evan

<eprodrom> Outie

aaronpk: before we go back to fr33domlover's questions, does anything else have anything to talk about? otherwise I think we should just go back to the original questions

aaronpk: okay so back to your architecture questions

fr33domlover: okay so because I'm doing this for project hosting I have lots of objects and concepts that are extensions to plain AP
... so my question is if I have things like new actor types, it won't just be like group, person, service, it'll be like issue, repo
... so if I have all these extra properties, does it make it harder for my app to federate with existing implementations
... like e.g. pump.io once they have AP
... so could someone on pump.io comment on an issue or whatever despite pump.io not understanding the extensions
... do I need to be careful about stuff to make sure I'm still compatible

<aaronpk> scribenick: aaronpk

ajordan: let me think about it for a minute
... citation needed, but I think pump.io should accept anything it doesn't recognize, so as long as you provide some sort of sensible alternative content, like a fallback description in summary, then it should display
... and you can certainly add comments to that
... it might not show up in the pump web UI or clients, i'm not sure, but you could use a pump account. like if you had a client that displayed issues you could use your pump account
... you would need to write your own JSON-LD context so other implementations can understand that
... pump.io probably won't end up caring about that, but other implementations do

fr33domlover: great i'll end up doing that
... the spec says you can treat the data as plain JSON, so do implementations usualyl understand JSON-LD? would that be a problem? or can I trust them to accept what they don't understand

ajordan: the answer is complicated. in the spec, all the authorization stuff is unspecified. in real life... let me find the wiki url

<ajordan> https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorizationhttps://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization

... what has happened in real life is all of the implementations have converged on this authentication scheme where server-to-server people use HTTP signatures and linked data signatures, so all implementations are full JSON-LD processing or they have a corner where they care about LD and the rest they treat it as plain JSON
... mastodon does it as mostly plain JSON, pump will do it as plain JSON
... kroeg does json-ld, not sure about the others

fr33domlover: so either way I need JSON-LD for the things you linked

<saranix> hmm... I suppose the same applies to my chat presense question... so if someone is "following" the room actor, they will get objects like { summary:"@foo is now away"}, but what should the type:{} be? Should it be a top-level activity of some kind? Since type:Add, object:type:{away status", etc.} seems kinda overly verbose

ajordan: if someone is consuming JSON-LD you can treat it as plain json except for the signatures. if you're producing data with extensions then you have to worry more about JSON-LD

fr33domlover: okay thank you

fr33domlover: one more question. I was thinking about inbox/outbox for actors
... it adds new addresses like actorid/inbox actorid/outbox
... that differs from RESTFUL applications where you can get and post the object ID directly
... I had this thought, suppose a project is an actor, since a project is part of the application itself, it's not a person, it doesn't need to GET its own outbox or POST to its inbox
... so the only things you need from an outbox and inbox for a project is people need to be able to post to an inbox to send changes and get from the outbox to see events
... so if I make the inbox the same url as the actor, and the outbox can have a url like actorid/changes
... then if I want to make a project into an activitypub actor, I don't need to add a new URL to my application
... since the changes are already visible as an HTML page, so I can use the Accept header to return the activitystream
... in regular REST applications you post to the object to make changes, so if you use the same URL for the inbox as the actor then you can use the content-type header whether you're receiving plain JSON or HTML form input, it all goes to the same URL
... so I was wondering if that's okay, and not surprising to other implementations, that the inbox URL and actor ID are the same

ajordan: off-hand, I don't think that should be a problem
... this has been discussed recently on IRC with saranix I think?
... it is worth noting that in activitypub, the client-to-server stuff is totally separate from server-to-server, so if you wanted to, you could implement a "regular" rest client-to-server API and then use activitypub for server-to-server.
... i'd encourage you not to of course, since if you implement activitypub client-to-server you get all the clients

fr33domlover: I noticed they're separate, and I agree I want the existing clients to be able to communicate
... so I think i'll go for what I said, making the inbox and actor id the same

ajordan: sounds great

fr33domlover: thanks for the feedback, i'm done asking questions for this meeting

<ajordan> np

<ajordan> scribenick: ajordan

<ajordan> aaronpk: thanks, great questions and I like trying to reuse existing URLs and things like that, sounds great ... well cool, anyone else have any new topics they want to squeeze in since we have a few extra minutes? ... I don't see anything on the wiki

<melody> i think saranix said they wanted to talk about chat on AP

aaronpk: alright well in that case let's call the meeting early

<saranix> BUMP: so if someone is "following" the room actor, they will get objects like { summary:"@foo is now away"}, but what should the type:{} be? Should it be a top-level activity of some kind? Since type:Create, object:type:{away status", etc.} seems kinda overly verbose

aaronpk: well thanks everyone for coming, hope it's been useful and let's do it again in two weeks

fr33domlover: yes thanks

aaronpk: and thanks ajordan for scribing

<ajordan> np! I've been slacking recently lol

<aaronpk> trackbot is slacking so I think i'm gonna have to generate the minutes manually

<trackbot> Sorry, aaronpk, I don't understand 'trackbot is slacking so I think i'm gonna have to generate the minutes manually'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<ajordan> wait

<ajordan> saranix is here

<aaronpk> ohai

<aaronpk> wait not on the call tho

<saranix> yeah I don't do mumble

<aaronpk> someone want to take the question?

<ajordan> saranix: I would think it would be an Edit on the Actor

<aaronpk> i'll leave you all to continue this in IRC :)

<saranix> ajordan: oh yeah, that makes sense

<ajordan> are we done on Mumble? my laptop is about to die

<saranix> ajordan: but AP requires Edits send the Full Object... which sucks for chat

<ajordan> scribenick: nobody

<ajordan> aaronpk: do we want to end the meeting? or what's happening

<ajordan> also

<ajordan> present+

<aaronpk> trackbot, end meeting

SocialCG/2018-03-28/minutes

Social Web CG

28 Mar 2018

Attendees

Contents