aaronpkdnegreira: i work for canonical but i'm here representing myself. i have some interests in activitypub and decentralized networks, i saw this meeting happening and was curious to see what was going on here
aaronpkemacsen: I'm serge, i'm not representing anyone, not even myself. i am currently writing an activitypub implementation that is going to be used as a tutorial of the process of creating an activitypub implementation so i thought it might be useful to lurk and see what people are saying
eprodromI'm Evan Prodromou, I am the co-editor of Activity Streams 2.0, founder of identi.ca, helped in making OStatus and ActivityPub. I work for the Wikimedia Foundation but not representing them in this meeting.
aaronpk... the point of spritely is to take a lot of ideas from surrounding communities and, in order to keep it from vaporware, releasing it as a bunc hof separate standalone demos
aaronpk... i just released one demo called gollum, to show off how you can distribute messages instead of by a live HTTP link, by distributing an encrypted and content addressed way where only the recipients can see the message but it can still be passed around a p2p network.
aaronpk... that's the description of spritely. i have two years of funding, not quite enough full time so i will be doing some contracting on the side too
aaronpktrwnh: my question is around content addressing. i know a lot of implementations don't do that. how much do you think it's possible to do that in existing implementations without fully extending activitypub
aaronpkcwebber2: current impls don't do that. one of the discussions we had was whether to require the https URI scheme. one of the reasons i pushed back against it is we might want to explore some other territories where we can retrieve things over schemes other than HTTPS.
aaronpk... let's imagine we took an existing implementation like mastodon, basically they'd have to be able to recognize not just https but also how to retrieve objects referred to by other protocols
aaronpkcwebber2: right this is an origin style approach. i agree the applications are being hardcoded to specific behavior around origins and that may turn out to be a problem
aaronpk... the original discussion was that we'll add that and it'll make it easy to add terms. the concern puckipedia raised last time is that doesn't capture the type information so we probably want to deal with that, otherwise it could lead to disjointness between the JSON-only and JSON-LD people
aaronpk... i'm not quite sure what bengo is thinking is happening here. he is thinking these refer to URIs but the ID and type are just aliases for @id and @type
aaronpkcwebber2: they also weird me out because it requires more work from people not using JSON-LD because it requires people look for two different things
aaronpkcwebber2: i don't see any reason why we wouldn't pull this in except if we wanted to demonstrate that if you dont supply a type then it defaults to object, but it doesn't seem like these two examples were explicitly trying to show that off
aaronpkcwebber2: for those who joined new, i apologize that you joined an issue closing meeting and also one where a key member isn't on the phone. but this is an important part, making sure the issues don't stagnate.
jolveraif an implementation read from other implementation, say mastodon, to show in my timeline their toots i'd have to save them in my database, right?
jdormit[m]Yeah, that's the idea. You don't strictly have to do it that way - you could just always derefence the object ids and retrieve them from their home servers, but that would mean tons of unnecessary network requests
trwnh oh
cwebber2 TOPIC: Open PRs on ActivityStreams 2.0, getting slight aged.. https://github.com/w3c/activitystreams/pulls
aaronpk ... the original discussion was that we'll add that and it'll make it easy to add terms. the concern puckipedia raised last time is that doesn't capture the type information so we probably want to deal with that, otherwise it could lead to disjointness between the JSON-only and JSON-LD people