Social Web Community Group Teleconference

22 Nov 2017

Attendees

Present: cwebber, puckipedia, sandro, nightpool, melody, tantek, cwebber2
Regrets Chair: cwebber2
Scribe: melody, cwebber2

aaronpk: with websub we've processed a bunch of feedback from the PR period, there are now two outstanding issues we need community feedback from -- it would be fantastic to get feedback from anybody using websub, i'll drop a link in the channel, and it'd be great to get input from the mastodon side, as it's critical to moving on to the next step of the spec

i'm not sure if that's gonna be easier for me

<cwebber2> https://github.com/swicg/general/issues/22

<Loqi> [cwebber] #22 Publishing which extensions are used by a server

cwebber2: we're onto the final item of the agenda which is publishing which extensions are used by a server
... if you want to be able to send some sort of message and be sure the other side actually knows how to handle that message
... we have a certain amount of extension built into the spec already as general extension mechanisms
... but you can imagine we have a social karma extension and if we want to treat that on both sides as a transaction, and you would want to know if the other side will handle it

i missed some middle here

<nightpool> aaronpk: can you give a more concrete example of how this doesn't solve the problem even if it *feels* like it does?

<sandro> +1 aaronpk this is an antipattern; thinking about fallbacks is good

<nightpool> I agree but it feels like it can be more strongly worded.

aaronpk: this has been tried before but testing for extensions hasn't really worked well, it just looks like it solves a problem but doesn't actually, usually better to think of fallback behavior

<Zakim> nightpool, you wanted to other failure

<aaronpk> lol zakim

<nightpool> text-only b/c i just woke up, so maybe someone can relay?

cwebber2: this might be more important when you are expecting an acknowledgement to a certain kind of message and are suprrised when one never arrives

<nightpool> But this is important for other types of failures as well

<nightpool> what if you try to pay someone, but their server went offline?

<Loqi>

<nightpool> We solved this for Follows with explicit Accepts and Rejects

<nightpool> So extensions which need confirmation should have explicit confirmation.

<nightpool> I don't think the problem needs to be any more complex then that.

<nightpool> Unless there's something else I'm missing?

<nightpool> fin.

<cwebber2> scribenick: cwebber2

melody: I just wanted to add that one of the things that testing for extensions would allow you to do is not attempt delivery at all if a server does not support a specific extension, which could be important as a type of fallback behavior which could be important as a security-intensive thing if the server does not support whatever you're trying to publish
... for example, if you're transmitting some sort of sensitive information that you wouldn't want it to display as just an arbitrary message that you don't want displayed explicitly if not handled, it may be better not to transmit at all

<scribe> scribenick: melody

<nightpool> +1 to sandro--just requiring a property on actors already covers everything this proposal could do

<Zakim> cwebber, you wanted to reply to nightpool

sandro: mastodon had this failure mode with private messages before activitypub, JSON-LD extension mechanism covers everything this proposal could do

cwebber2: the explicit ack might be important anyway because if you do a federated add to a collection and the collection isn't owned by your server we don't have any mechanism to have any sense of whether the add happened, only a request to add
... if i see that a request to add a photo to a shared curated album i don't actually know whether it happened i only see the request

i'm sorry i missed that last bit

<nightpool> cwebber2 I think sandro's point was a little stronger then you summarized it

<cwebber2> cwebber2: maybe accept/reject are good enough for an ack/nack but maybe we want something else?

<nightpool> In that an "extension" endpoint is a complete subset to having a property, with that *same uri* that just says "true"

<nightpool> We could probably move to a resolution to close this issue given it sounds like we have consensus?

cwebber2: i agree we probably don't want to add another layer of indirection at this point

<nightpool> Ah, sorry puckipedia was still typing that when you spoke up

puckipedia: a while back we mentioned we might have a server actor for server-wide information, maybe for some extensions we can make sure that they are on the server actor

cwebber2: if we go the direction of adding properties, there's no reason you couldn't use them on the server actor in that way

<nightpool> there was a github issue.

<aaronpk> sandro++

<Loqi> sandro has 52 karma in this channel (59 overall)

<nightpool> and vague conversation w/ the glich-soc people

sandro: was there an actual problem somebody was having that prompted this issue?

<nightpool> let me see if I can scare it up

cwebber2: yes, but have not described it

<nightpool> https://mst3k.interlinked.me/@Elizafox/1517781 is the thread

<Loqi> [Eliza 「SHITPOST 2 U」 KSC] Is there any way with ActivityPub to discover what features a target server supports?

<nightpool> https://github.com/swicg/general/issues/22 is the issue under discusion

<Loqi> [cwebber] #22 Publishing which extensions are used by a server

cwebber2: are we ready to close the issue?

sandro: yes, we can point to these minutes and explain that it doesn't seem useful for the use cases so far

<nightpool> C2S is maybe a point here we haven't brought up yet?

<xmpp-social> [ajordan] Oh yikes completely forgot about the telecon... oops

<xmpp-social> [ajordan] And I gotta pack now :/

<xmpp-social> [ajordan] Have fun though!

<nightpool> reading this thread/and the tagentially related glitch-soc issue by surinna https://github.com/glitch-soc/mastodon/issues/123

<Loqi> [ekiru] #123 Expose some description of functionality supported by the instance in the API

cwebber2: the mechanism we're discussing seems to work just as well for client to server

<nightpool> Right, that makes sense. Thanks.

sandro: the client would just have to know where to look

<nightpool> to be clear: this is the glitch fork, not the mastodon project

<nightpool> ah yes. the "spam" filter

<nightpool> sandro++

<Loqi> sandro has 53 karma in this channel (60 overall)

<nightpool> https://cybre.space/about/more

<nightpool> https://octodon.social/about/more is another example

account migration WIP on mastodon

should i start scribing again?

<nightpool> https://github.com/tootsuite/mastodon/pull/5746

<Loqi> [Gargron] #5746 Profile redirect notes

nightpool: we have a new property on actors that say "this user has moved to this location" which is just displayed and does a soft redirect and the mastodon web UI disables the follow button

<cwebber2> https://github.com/tootsuite/mastodon/pull/5746#pullrequestreview-77611085

cwebber2: i noticed that moved to was added to the AS namespace so this is a good time to talk about our extension process

<nightpool> Given that none of the CG members that aren't part of other working groups can use the wiki, i'm still somewhat -1 on using it for extensions.

cwebber2: we talked about letting implementers take the lead and try out changes before we decide whether to add something officially to AS

<cwebber2> https://www.w3.org/wiki/Activity_Streams_extensions

sandro: could also add them on a provisional basis

cwebber2: it seems less provisional if a major implementer releases something while it was in the spec

<tantek> what does "Provisional" mean? that's the problem here IMO

<Zakim> tantek, you wanted to note we should name any "phases" by what they mean in practice, rather than an abstract term IMO

sandro: we could make a wiki for the community group since almost anyone can join

tantek: recommend against a community-group-specific wiki, when the group ends, it's hard to transition things and nobody has made it work in practice

<nightpool> or having an "implemented" group or something

<cwebber2> https://www.w3.org/wiki/Activity_Streams_extensions#Proposed_extensions

cwebber2: so right now there's no mechanism for moving an extension away from "proposed"

<nightpool> +1 to extend

<cwebber2> +1

+1 to extend

<sandro> +1 ten minutes

cwebber2: Given that people can't edit the wiki, propose we move the extension process into a github repository, people can use pull requests on a markdown document to contribute and discuss

sandro: we could convert the existing document to markdown

cwebber2: i don't think we need all the core stuff, we could do a document with just the extension info

sandro: wouldn't it be easier if there was only one place to look up vocabulary?

cwebber2: might be a lot to read through
... which repository should we use? ActivityPub, New Repo, ActivityStreams?

<Zakim> cwebber, you wanted to suggest a github repo

cwebber2: going to create new repo

nightpool: there may be vocabulary that we haven't thought through in a fully general context, liked moved to
... if we make a new repository it should be for general activitypub extensions not just activitystreams

i missed scribing some discussion about activitypub technically being an extension of activitystreams, so activitypub extensions are all activitystreams extensions

movedTo

nightpool: having seperate documents gives more room for adding historical information, context, and rationale

<tantek> oh boy, AP is much more than an AS2 extension

<tantek> AS2 extensions were intended to be vocab only IIRC

<tantek> and AP introduces tons of features / protocols etc. above & beyond AS2 - it's a new spec

nightpool: movedTo is a first step towards migration, just the first, easiest, simplest thing out there, when you want to move you specify the actor you want to move to, the actor provides a confirmation

sandro: so this does not automatically move subscriptions/etc

<tantek> I'm worried that a partial solution to migration may actually slow down or block a more complete solution that moves subscriptions etc.

<tantek> I realize perfect is the enemy of good and all that

cwebber2: there was some talk of using a move activity to do the migration and subscriptions

<tantek> but in this case I feel it may actually be counterproductive

<nightpool> cwebber2++

<Loqi> cwebber2 has 106 karma

<aaronpk> cwebber2++

<Loqi> cwebber2 has 107 karma

<cwebber2> melody++

<Loqi> melody has 1 karma

<cwebber2> trackbot, end meeting

SocialCG/2017-11-22/minutes

Social Web Community Group Teleconference

22 Nov 2017

Attendees

Contents

account migration WIP on mastodon

movedTo

Summary of Action Items

Summary of Resolutions