Social Web Working Group Teleconference -- 25 Oct 2017

<cwebber> scribenick: aaronpk

cwebber: most of the topics today are a holdover from last week

<cwebber> https://www.w3.org/wiki/SocialCG/2017-10-25

Social WG Updates

cwebber: the activitypub test suite is live

<cwebber> https://test.activitypub.rocks/

cwebber: but still hammering out the bugs with puckipedia
... so that will take at least the rest of the day before announcing it publicly
... we are hoping to go to PR by the 14th of next month
... that means getting the test suite really done, doing all the planned edits, and getting implementation reports in
... aaron there was something about websub

<cwebber> aaronpk: we talked about a couple of minor editorial edits, and someone submitted a full review, but also yesterday we got a new implementation in the wild... twitch.tv has a new webhook platform using websub so that's exciting

ajordan: ryan barrett launched fed.brid.gy and that has successfully been used to reply from an indieweb site to a mastodon post

so that seems to be working now which is phenomenal

<csarven> cwebber: https://test.activitypub.rocks/ is a 502 for me.

<ajordan> fed.brid.gy

<cwebber> csarven: oops

nightpool: they haven't quite replied yet because it doesn't show up as in reply to but the post itself did federate

<ajordan> neat

<cwebber> csarven: no idea what happened will look post-meeting

<cwebber> csarven: this version is bridging to my own local testdev instance for just the moment, heh

media upload as extension

cwebber: the mediaUpload is moving to the CG to standardize as an extension
... we need to start the process
... iguess that's on me unless someone wants to step up

nightpool: what does the process look like for extensions?

cwebber: i think it's still somewhat ad hoc

<rhiaro> icymi I ripped media upload out and put it on the cg wiki yesterday https://www.w3.org/wiki/SocialCG/ActivityPub/MediaUpload

cwebber: someone ends up writing it up in this group and brings it to a meeting and we discuss it and ratify it as an official document through a vote

<cwebber> rhiaro, yay

ajordan: i might be willing to work on a document or two in a couple weeks

<Loqi> :D

ajordan: if noone else volunteers i might be able to do that maybe question mark

cwebber: you were also looking at activitypub implementation in pump.io?

ajordan: yeah that's one of the things i need to do in the next couple weeks before i commit to anything else

cwebber: amy on IRC points out she moved the media upload section to the wiki

ajordan: what would we need to be prepared to have a discussion on that?
... we want to look at other implementations like twitter?

<ajordan> basically what are our action items here

cwebber: here's the challenges the media upload endpoint was hitting
... creating an activitystreams object and uploading the media in one swoop which might be fine but one challenge is you wouldn't want to do the create at the same time if you were going to attach it to something else
... puckipedia and i came up with something which is whethre you wrap it in create is whether it shows up in your outbox
... but that didn't take into account chunked uploads

<ajordan> thanks

<er1n> o/

<cwebber> q

follower migration

<cwebber> https://github.com/swicg/general/issues/1

<Loqi> [sandhawke] #1 Follower Migration

cwebber: this issue has a lot of discussion
... a number of different routes have been discussed
... one would be to have some sort of "move" activity

<cwebber> https://github.com/swicg/general/issues/1#issuecomment-331567958

<Loqi> [Gargron] ```js

<Loqi> {

<Loqi> type: 'Move',

<Loqi> actor: 'uri/to/alice',

<Loqi> object: 'uri/to/alice',

<Loqi> target: 'new_uri/to/alice'

<Loqi> }

<Loqi> ```

<Loqi> Sent out to followers.

<Loqi> Old server's webfinger would need to redirect to new server's webfinger, and new server's webfinger woul...

cwebber: why not codify it as an AS2 object to move one user to another
... one downside is it wouldn't preserve the URIs of the old activities
... one reason mastodon didn't do this is it would allow someone to take a big action all at once. but now mastodon has the option to delete an entire user all at once.

<jaywink> FYI. here is the diaspora protocol account migration entity, for reference: https://diaspora.github.io/diaspora_federation/entities/account_migration.html

cwebber: another route would be to have some sort of decentralized identifier

<cwebber> https://w3c-ccg.github.io/did-spec/

cwebber: DIDs are a combination of replacing DNS and SSL authorities at the same time

<cwebber> https://project.hubzilla.org/help/developer/zot_protocol

cwebber: another option is zot's version of nomadic identity
... which i don't entirely follow. i did take a look at it at one point and when you boil it down it is namespacing a combination of what's effectively the domain it's posted on and someone's unique key

<nightpool> (to close the loop async: msatodon does parse a Delete { Actor } as deleting an entire actor and all of their content, but doesn't expose this to users in any way))

cwebber: the goal is if you make a post the post has an ID and even if the server is down the post still is identifiable
... so, the last one is HTTP redirects
... which could be combined with a move activity
... maybe you do the move activity and set up http redirects on the old objects

puckipedia: i've been playing with activitypub, and i was thinking of storing the objects as a hash of the object but then you get immutability. but i did take a look at the decentralized IDs and the question is are one of those enough to find the user or object?
... if you can't take an object ID and find its data then that's kind of the issue with migration

<cwebber> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/activitypub-decentralized-distributed/activitypub-decentralized-distributed.md

cwebber: in this paper i effectively show how you end up mapping a decentralized identifier to an activitypub object

<cwebber> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/activitypub-decentralized-distributed/activitypub-decentralized-distributed.md#distributed-identity

cwebber: you should be able to use DIDs in one of two ways.
... you can replace the objects with DIDs. for example one uses IPFS, another uses bitcoin blockchain, another uses a specific blockchain
... but they all provide the mechanism of having a linked data object for someone's key and a way to migrate keys
... so if you lose your phone, you can say if 2 out of these 3 people say it's okay then you can switch to the new key
... so the example in there shows an activitypub service, it links you to the activitystreams object for the user. but you can also link to it itself
... so if the receipient is something like this:

<cwebber> {"to": ["did:example:d20Hg0teN72oFeo0iNYrblwqt#services/ActivityPub"]}

cwebber: you could resolve the object and pull down the activitystreams actor
... there's also a mechanism to do something like HTTP get and post but that's a bit underspecified
... so there is a way to be able to resolve the object with the DID itself.
... i think there's a way to move to DIDs instead of domain names
... but there's not a clear path to moving from domain names to DIDs. it's clearer if everything uses DIDs from the start

puckipedia: maybe we could define a property like "alternate IDs"

cwebber: i'd need to think more of the consequences of that

nightpool: i'm trying to follow along. can you give a 10000 foot overview of how resolution of IDs work?
... i remember some past discussions there was some concern over how web-like these mechanisms are

cwebber: there are multiple methods of resolution for DIDs, each specifies its own
... in the main DID protocol we're not sure which of the mechanisms are going to work out. the IPFS is probably the most promising
... the bitcoin one has a lot of overhead. the other one has probably the least overhead
... but the different methods need to specify the behavior of how to resolve

<nightpool> can someone link the veris(sp?) protocol? googling doesn't seem to be turning anything up

cwebber: there are multiple DID methods. bitcoin, ipfs, veris. they each provide a create, retrieval and update method.
... however, some of those may require pulling down a large amount of information, such as bitcoin requiring pulling the whole bitcoin graph
... so similar to how people don't host the whole DNS database, you can have resolvers doing resolution as a proxy

nightpool: right now existing implementations are based around HTTPS, so moving from that to a system that's more complicated seems to be a hard ask

cwebber: so we're exploring multiple methods of follower migration. HTTPS methods require the previous instance be online
... if there's no redirects then none of the servers will know the content moved
... if you have a DID then it's more resilient if a server goes down
... so how will be implement the resolvers
... i think you just have a library and point at one or more resolvers
... you'd be able to say get this DID and point at the resolver you want
... so we're presuming that it's unlikely that every mastodon server will host a DID database

nightpool: that brought some clarity but also raised more questions
... wer'e talking about these DIDs like they're completely interchangeable. but all of them have vastly different drawbacks and affordances.
... it seems like from an implementation level we can't just push it to a library and have it do the right thing

cwebber: when i was talking about the hub and resolvers, i was talking about a resolver that handles all the methods for you under the same interface
... where do we go from here? any comments?

<cwebber> scribenick: aaronpk

<cwebber> aaronpk: this feels like going down quite a rabbit hole... I'm a bit confused because everything going around this point has been based around HTTP and very web-like protocols, and up until this point we've been talking about very web-like things

<ajordan> aaronpk: sounds like kinda what you're saying is, are we making the right tradeoffs?

<cwebber> aaronpk: I realize DNS can go down and you're stuck, but you're very likely to have issues with these other systems and we might not know what this is. one benefit of https is dns is not tied to a server, you can move it to a new server etc without having to change your identity... so it seems like http/dns are very natural fits for this, esp in the context of the web, this is the social web community group

cwebber: i think you're right, https is well understood and widely implemented. it depends on what definition of the web you're talking about.
... and you're also right that these are kind of out-there tehcnologies that haven't proven themselves yet
... i'm not saying these are things we should necessarily do, just trying to look at paths to explore
... and trying to find patterns that map more closely to the things we use
... so i'm saying here are some paths we coud potentially go down

ajordan: obviously we dont want to end up with a bunch of different ways to do follower migration. but it sounds like some of the things we're discussing here are breaking changes anyway.
... so if we start addressing everything with DIDs then it sounds like that would already be a breaking change in the sense that any server on the network that couldn't resolve those addresses would be screwed
... so i'm wondering can we do something now, and explore these farther out options later

cwebber: that makes sense, that's what i was hoping to push here. get a discussion of what kind of thing we can do now and what can we look for in the future.

ajordan: so we can do things in parallel too. we can ship a minimum viable solution, like shipping http redirects.
... with the assumption that the far-out things would take longer since we would have to build more stuff and also wait for underlying specs to mature as well

cwebber: so now it's a matter of what people are interested in implementing right now
... it might end up being that the best way to continue this discussion is to coordinate if some of these paths start to get implemented

nightpool: when we talked about this on the mastodon issue about how to delete a user, you mentioned some kind of extension type that specifies side effects like migrating content
... and in the case of deleting a user should that delete all of the activities or should it just make the user inaccessible
... maybe the way forward here is thinking about extensions in that area
... so you could move an actor and say to also rewrite all the IDs
... or you can move an actor and it will just change the representation of the actor in the system

<Zakim> cwebber, you wanted to talk about rewriting ids

cwebber: what you brought up of what if the move activity also provided some sort of rule to rewrite IDs. i'm a little worried it will be hard to get right
... reason 1 is you could imagine someone writes a regex to rewrite from one system to another. regexes are pretty messy
... but also it could open a vector of attack, you could end up saying move all my posts and also gargron's. so i'm nervous about the template rewriting thing. but you're right that if we get this to work we need to figure out howto get it to work correctly

<ajordan> I don't think you'd need regex-level template rewriting

<nightpool> rewriting IDs from something like https://example.org/ID to something like https://new.server/authority/https://example.org/ID is probably doable

<ajordan> I think we might be able to just get away with specifying a less powerful system and then you avoid all those vulns

cwebber: yes specifying a less powerful system would be good. maybe we can start by writing a wiki page about it

nightpool: if you're thinking about some sort of template thing, you can hold the signed move activity and any server that missed it can verify it using linked data signatures
... so if you have an authentication protocol like that in place then you dodged the "oh the server has to be up" issue
... because any server can have a signed activity and send it to another server

cwebber: so if the actor has the same key as they had on the previous server, you can be sure it's the same user?

nightpool: yeah if you have the key for nightpool@cyber.space you could import that into a new server and let me sign things as nightpool@cyber.space
... so maybe this is a little out of spec since mastodon currently thinks of keys as authoritative and there isn't guidance on that in activitypub, we resolve keys through webfinger and map them to users that way
... i'm not really sureh ow linked data signatures fit into the spec as written
... but if i can prove i'm acting on behalf of an actor then i don't need to worry about the decentralized ID tihng

cwebber: so mastodon does attach the public key to actors. so if you have a cached copy of the key on an actor and you're able to demonstrate you have the key, then you can do it even though you can't do webfinger requests anymore
... also users would have to be able to download the key associated with their profile so that they can upload it to the new server when they move over

<nightpool> +1 for deferring, but maybe give a quick summary?

<ajordan> I cannot extend

can't extend

publishing extensions

cwebber: currently in activitypub, there is an extension mechanism for vocabularies. you can have a way to specify new vocabularies not defined in activitypub, but you don't have a mechanism to be sure that the side effects of the activities will be understood by the other servert.
... so that's what this proposal is about, defining what type sof activities your server is able to understand the side effects for
... the extension provides a new endpoint that gives back a list of all the extensions represented by URIs that I know how to handle

<ajordan> I herd u liek extensions

<cwebber> haha

<Loqi> rofl

<nightpool> sgtm

<ajordan> so I put some extensions in your extensions so you can extension while you extension

<ajordan> aaronpk++ for scribing!

<Loqi> aaronpk has 96 karma in this channel (1450 overall)

<cwebber> aaronpk++

<Loqi> aaronpk has 97 karma in this channel (1451 overall)

<nightpool> aaronpk++

<Loqi> aaronpk has 98 karma in this channel (1452 overall)

<ajordan> cwebber++ for chairing too

<Loqi> slow down!

trackbot: end meeting

<ajordan> cwebber++ for chairing too

- DRAFT -

Social Web Working Group Teleconference

25 Oct 2017

Attendees

Contents

Social WG Updates

media upload as extension

follower migration

publishing extensions

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output