Social Web Community Group Teleconference

03 Jan 2018

Attendees

Present: eprodrom, cwebber2, melody, puckipedia, beatrix-bitrot
Regrets Chair: None (informal IRC meeting)
Scribe: None (informal IRC meeting)

<cwebber2> eprodrom_: meeting is now if you want to join :)

<puckipedia> okay I'm here

<cwebber2> oh hey its beatrix-bitrot :)

beatrix-bitrot waves

<cwebber2> beatrix-bitrot: puckipedia and I just got off the call because we thought nobody else was showing up but maybe you'd like to talk about groups?

<cwebber2> I think we have a pretty short summary of things tho

<beatrix-bitrot> ok well maybe hit me with the summary first i guess?

<cwebber2> Group should just be an actor with an inbox (publish to group) and an outbox (read the archives!)

<beatrix-bitrot> i would like to talk about it since this seems to be the right time and place

<cwebber2> you could even use the Follow mechanism to do group management.

<beatrix-bitrot> right

<puckipedia> and to address a post you'd do something like {"to": ["https://example.com/group", "https://example.com/group/followers"]}

<cwebber2> {"type": "Group",

<cwebber2> "inbox": "https://...foo.../inbox", <- send messages to group

<cwebber2> "outbox": "https://...foo.../outbox" <- read archives

<cwebber2> "followers": "https://...foo.../outbox"} <- current subscribers

<cwebber2> puckipedia: maybe you don't even need to include the followers to address, I dunno

<cwebber2> since that's the actor's "behavior"

<puckipedia> cwebber2: I feel like you should, to make it clear

<beatrix-bitrot> that's what i was just about to ask

<beatrix-bitrot> why that?

<puckipedia> cwebber2: also, sharedInbox

<cwebber2> hm, sharedInbox is such a PITA ;)

<cwebber2> but yeah

<cwebber2> puckipedia: thinking from an actor as in actor model perspective

<cwebber2> I'd think of this as being a relay type actor

<puckipedia> bad idea: {"type": ["Group", "OrderedCollection"], "id": "example", "followers": "example"}

<puckipedia> wait this gets dangerously close to giving collections an inbox :D:

<cwebber2> honestly I think a group should forward to all its actors' inboxes individually and should skip the sharedInbox mechanism

<puckipedia> mmh?

<cwebber2> *especially* because you don't know who's in the group necessarily

<puckipedia> cwebber2: you do know if you use the follow mechanism, tbh

<cwebber2> this is how mailing lists already work over smtp

<puckipedia> I mean

<puckipedia> hm

<puckipedia> HM

<puckipedia> I thought it'd be like origin -> group server -> sharedInboxes

<beatrix-bitrot> i was imagining the follow mechanism would be used for this yeah...

<beatrix-bitrot> and also like puck says just now

<puckipedia> wait, I think we are hitting the post forwarding mechanism now :D

<beatrix-bitrot> yes

<beatrix-bitrot> this is what i wanted to talk about

<puckipedia> https://www.w3.org/TR/activitypub/#inbox-forwarding this

<beatrix-bitrot> oh

<puckipedia> The values of to, cc, and/or audience contain a Collection owned by the server.

<beatrix-bitrot> ?

<cwebber2> puckipedia: in a sense that's what I'd like to *not* trigger here

<puckipedia> mmh

<cwebber2> the forwarding mechanism can result in duplicates

<cwebber2> and you really don't want to do that for groups

<cwebber2> just let the group send it out

<cwebber2> the group knows where it's supposed to go

<puckipedia> cwebber2: wait. are you thinking of the same thing

<cwebber2> no need to involve the group's followers at all

<puckipedia> cwebber2: I mean, if you have to: example, example/followers

<puckipedia> you deliver to example, and you can't deliver to /followers because you don't own it

<puckipedia> then example delivers it to all followers, using sharedInbox

<cwebber2> puckipedia: right, in which case, if we switch to group group/followers

<cwebber2> we would do it twice right?

<cwebber2> the group would forward it, then the followers would forward it, and it could be a big mess

<puckipedia> oh, you expect that group is sending it out

<puckipedia> I would suggest Not Doing That(TM) :P

<cwebber2> yes

<puckipedia> but yeah

<cwebber2> I think it should be like SMTP mailing lists

<puckipedia> hm

<puckipedia> what if we drop the outbox on the Group

<cwebber2> the FOSS world already runs on those and has been doing fine :)

<cwebber2> outbox should be optional

<puckipedia> and have it just have an inbox. which is the incoming messages

<cwebber2> in case you want to allow reading archives

<puckipedia> which /also/ is the outgoing messages, because relay

<cwebber2> it could also be subscriber only access to the outbox

<puckipedia> beatrix-bitrot: right, we're now really looking at the nitpicky details, sorry about that

<cwebber2> puckipedia: ah I see what you're saying

<cwebber2> puckipedia: though

<beatrix-bitrot> i can't talk much about the details but i want to absorb what i can

<cwebber2> puckipedia: I kind of hate readable inbox tbh, *nothing* currently reads from your inbox

<cwebber2> right?

<cwebber2> it's so dangerous to let someone read from your inbox

<cwebber2> I think all applications, in practice, show an empty collection

<puckipedia> https://puckipedia.com/inbox

<cwebber2> readable outbox is something people currently do

<cwebber2> ha

<cwebber2> ok

<cwebber2> I'm wrong :)

<puckipedia> tbh, inbox/outbox are just plain collections

<cwebber2> puckipedia: so here's a question

<puckipedia> and only show public posts, so I consider it Fine(TM)

<cwebber2> should the group forward the message as-is

<cwebber2> or wrap it in an Announce

<cwebber2> that also may affect whether we choose inbox or outbox

<puckipedia> would it be logical to announce another announce?

<cwebber2> sure

<cwebber2> why not

<cwebber2> recursion is great

<cwebber2> puckipedia: but announces are unlikely to show up in groups anyway

<puckipedia> tbh I would suggest not Announcing a non-activity

<cwebber2> hm

<puckipedia> cwebber2: {type: Announce, to: group..., object: otherPost}

<cwebber2> yeah maybe they should just forward the messages as-is

<cwebber2> though, let's think SMTP mailing lists again

<cwebber2> when someone sends a message to the SMTP mailing list

<cwebber2> Mailman or whatever *does* append headers to it

<cwebber2> indicating it came from the group

<cwebber2> so in a sense that's closer to wrapping in an Announce

<puckipedia> *but* the message is sent as-is

<cwebber2> it isn't usually

<cwebber2> well

<cwebber2> the body is

<puckipedia> also smtp doesn't have retoots

<cwebber2> lol

<cwebber2> also wait

<cwebber2> the body sometimes isn't either!

<cwebber2> some mailing lists append a footer

<cwebber2> for subscribe/etc

<cwebber2> I'm not saying it's a good idea

<cwebber2> I'm just trying to explore what's done in existing spaces

<puckipedia> GNU Social groups require you to effectively tag a post

<cwebber2> also, we should think carefully:

<cwebber2> is an announce maybe required in practice *anyway*, because of http signatures?

<puckipedia> cwebber2: we'd resign the object with http sigs, but the json-ld signature would stay

<cwebber2> puckipedia: right, but is there anything wonky if I'm forwarding a mechanism with the actor at puckipedia.com but my server is dustybutt.org and I have an http signature from dustybutt.org

<cwebber2> I guess you specify what actor it's coming from in the http sig itself

<beatrix-bitrot> the json-ld one is the one that verifies it really came from the alleged author?

<cwebber2> beatrix-bitrot: yes

<puckipedia> iirc Mastodon resigns objects when doing the mention forwarding

<puckipedia> ehm, resigns the requesT*(

<puckipedia> honestly I haven't looked too closely at it

<melody> hrm

<puckipedia> I just kinda discard the entire contents of the object

<puckipedia> as I don't have JSON-LD validation yet

<beatrix-bitrot> ehmmmm how does it differ from boosting?

<puckipedia> beatrix-bitrot: mention forwarding?

<beatrix-bitrot> or how groups ought to work

<cwebber2> beatrix-bitrot: boosting uses the Announce wrapper

<cwebber2> so that's part of what we're discussing

<cwebber2> whether or not it should use that

<puckipedia> {type: Create, object: {type: Note, content: hi}}

<puckipedia> vs

<cwebber2> however, the forwarding mechanism doesn't wrap it

<puckipedia> {type: Announce, object: that_note_there}

<cwebber2> puckipedia: I think you've convinced me

<puckipedia> mention forwarding is a different thing. if you mention someone and it reaches their server, it will send it out to all followers, with json-ld

<cwebber2> we shouldn't wrap in Announce

<puckipedia> cwebber2: :D

<cwebber2> for another reason too:

<cwebber2> it may look confusing for UIs

<puckipedia> yes most definitely

<cwebber2> it may show up looking like a share

<cwebber2> when it isn't

<puckipedia> also what if you announce an announce from a group back into the group :D:

<cwebber2> I think I never would have suggested wrapping in Announce if Announce were called Share, as it should be D:

<cwebber2> oh well

<cwebber2> lol

<beatrix-bitrot> so this stuff being discussed now

<beatrix-bitrot> does it need to be written up somewhere?

<puckipedia> this channel's logged, but we might write up a more formal specification, I guess?

<cwebber2> yeah

<melody> how would you know if a message is forwarded from a group?

<cwebber2> we could start an etherpad

<beatrix-bitrot> yes i was thinking of specifications

<puckipedia> melody: do you need to know?

<cwebber2> puckipedia: I sort my smtp mail by mailing list

<cwebber2> so you might want to

<puckipedia> oh that

<puckipedia> I thought 'announcing a post from a group'

<cwebber2> but, I suppose you could sort by addressing

<melody> UIs could have a good reason to distinguish

<beatrix-bitrot> UIs definitely have reason to distinguish

<puckipedia> yeah, I misunderstood again

<melody> if I follow a lot of people I might not recall offhand if I'm following somebody or if a post I've seen is in my inbox because it came from a group

<melody> i want to know the immediate source of any message i'm seeing usually

<cwebber2> melody: and indeed that's one reason that Mailman etc relay add headers

<cwebber2> I think we used to have Announce and Share separately in AS2 for exactly this use case D:

<beatrix-bitrot> is there no way to include the information that it was relayed other than wrapping it up?

<cwebber2> we could have a new activity for forwarding

<cwebber2> beatrix-bitrot: well it either needs to wrap it (message integrity, after all you can't tamper with something signed) or it could be in the headers of the HTTP POST to the inbox

<cwebber2> but, in that case your server might know

<cwebber2> but you, reading from a client, might not

<cwebber2> that info wouldn't show up in the inbox without wrapping the messages again

<beatrix-bitrot> your server will have to tell you somehow anyway no?

<cwebber2> yes, but consider that an inbox is possibly one json object with a bunch of other json objects embedded

<cwebber2> you'd need to wrap there right?

<cwebber2> if your server were to tell you

<cwebber2> and it wasn't going to tamper with the messages

<cwebber2> wrapping seems the only way

<melody> i don't think it makes sense for the server to be acting on invisible info not wrapping the objects

<beatrix-bitrot> but you do not want to wrap, correct?

<cwebber2> beatrix-bitrot: we definitely don't want to wrap in Announce (ie "share")

<cwebber2> but we could possibly have a new type

<cwebber2> that's just Forward or etc

<cwebber2> or ServerForward

<cwebber2> or something

<cwebber2> maybe not a good idea to get the word Server in there

<beatrix-bitrot> right

<cwebber2> but

<cwebber2> it also means that all AP servers and clients need to understand that new wrapping object

<cwebber2> and its type

<cwebber2> and know what to do with it

<melody> i think creating a new type would require some additional thought, not that I'm advocating using Announce, but I'm not sure that the semantics of Forward really serve all group use cases

<cwebber2> extra logic

<cwebber2> melody: I agree it would take additional thought

<cwebber2> so here's a question

<beatrix-bitrot> i can only really take your word for it that Announce is not the right thing ^^;;

<cwebber2> beatrix-bitrot: allow me to demonstrate :)

<cwebber2> what does Mastodon do when it gets an Announce currently?

<cwebber2> it treats it as a repost right?

<cwebber2> and it even shows it in the UI with that arrow reposty icon

<eprodrom_> cwebber, sorry I missed it. I was up with a sick kid all night.

<cwebber2> what would happen if we overloaded the meaning of Announce and used it for two different things

<cwebber2> eprodrom_: it moved to an informal IRC meeting!

<cwebber2> so you can read the backlog and participate now if you'd like

<eprodrom_> ok great

<melody> i mean that's what a group is doing in this scenario isn't it? reposting something by somebody else for its own audience?

<cwebber2> we're talking about Groups

<eprodrom_> oh yeah

<beatrix-bitrot> yes

<eprodrom_> announce is great there

<cwebber2> melody: yes, but now imagine you're getting a ton of messages addressed to groups

<eprodrom_> Announce++

<Loqi> announce has 1 karma

<cwebber2> if I send a message to tofu-lovers

<cwebber2> every message I send there

<cwebber2> should it show up in the UI as if tofu-lovers had reposted it?

<eprodrom_> oh

<cwebber2> even if that's the first time you get it

<eprodrom_> yes!

<melody> arguably, yes

<cwebber2> really?

<cwebber2> I think this would be confusing for me, thinking about Mastodon's UI

<beatrix-bitrot> or it should be up to the system displaying it to decide anyway

<cwebber2> I feel like I'd want a different type

<cwebber2> beatrix-bitrot: but the system would have to know the difference!

<cwebber2> I'm saying these are semantically two different

<cwebber2> things

<beatrix-bitrot> system need only know tofu-lovers is a group right?

<eprodrom_> between a share from the group, and a share from a person?

<cwebber2> in fact I think they used to be... we used to have Announce vs Share iirc...

<eprodrom_> that seems pretty clear

<cwebber2> I mean

<cwebber2> you could look that up

<cwebber2> that the actor is a Group

<cwebber2> I feel like I'm not wild about it though I agree you could use that to visually distinguish it

<cwebber2> eprodrom_: I think we used to have Announce vs Share in AS2 for this very reason but merged them maybe?

<puckipedia> what if you limit Activities to a Group to [Create, Announce]?

<Loqi>

<melody> I'm not personally wild about the behavior of groups being treated as forwarding relays, I can't think of anything except mailing lists that works that way

<cwebber2> melody: well effectively that is what groups are :)

<cwebber2> mailing lists

<melody> should that be what groups are though?

<eprodrom_> if you want groups to put stuff in your inbox

<beatrix-bitrot> i am interested in how else they might be

<eprodrom_> melody they can be more

<eprodrom_> but this is mostly how they work on FB

<eprodrom_> possible also to tease out group from collection of members from collection of admins

<eprodrom_> so

<melody> Like, I guess I'm unclear what groups in this context are supposed to be replicating maybe

<beatrix-bitrot> it's a way to send stuff to some set of people that don't necessarily follow you conveniently right?

<cwebber2> sounds like a mailing list :)

<beatrix-bitrot> as far as i am concerned it doesn't really need to replicate anything if it does that well

<beatrix-bitrot> like a mailing list, or a chat room, or probably lots of things

<beatrix-bitrot> i would like to be able to have a conversation like this using a group

<cwebber2> I agree on that point!

<cwebber2> there's no reason we need to replicate the delayed level of conversation of mailing lists ;)

<melody> my concern is about things like permissions -- who can post to a group? groups should have membership semantics that don't necessarily dovetail cleanly with follow/forwarding semantics

<puckipedia> I think this is mostly unspecified, I guess?

<cwebber2> melody: well, if we think of mailing lists again, our Follow mechanism actually does nicely match

<cwebber2> since we have explicit Accept/Reject

<cwebber2> so we can emulate moderated subscription

<melody> i don't think we should be emulating mailing lists abuse prevention mechanisms

<melody> monumental disaster

<cwebber2> melody: heh, these are two separate tricky questions, but I agree we should consider them together

<beatrix-bitrot> ok, so who can post to a group? is that even a protocol level thing?

<cwebber2> though that may mean multiplying the complexity of a conversation ;)

<puckipedia> beatrix-bitrot: probably not

<cwebber2> beatrix-bitrot: I don't think so, I think the group can decide... but you can probably infer based on whether you're a follower

<cwebber2> but the group may decide to not send along your message if some filter decides not to, for instance

<beatrix-bitrot> maybe some groups allow posts from anyone, maybe some only from followers

<cwebber2> sure

<melody> a client should have a mechanism to determine whether you can post to it or not

<melody> so that would need to be defined behavior

<cwebber2> melody: well... though you might not know in advance if your *specific* post can get through

<melody> otherwise you get nasty UX with messages that just never materialize because you didn't know you couldn't post them

<cwebber2> eg I may be generally subscribed to a mailing list

<cwebber2> and I can send messages generally

<cwebber2> but my message got rejected because it looked spammy

<melody> you should know if you can send messages generally though, regardless of if it also gets filtered out later

<beatrix-bitrot> i guess if you tried to post to a group you couldn't post to for whatever reason the server should give you a 403 or something

<cwebber2> melody: maybe an Accept on your Follow is good enough to indicate that?

<cwebber2> that's how your client accrues information that it knows you're part of the group

<Loqi> yea!

<beatrix-bitrot> that couples accepting messages and distributing them tho

<melody> what if a group wants to allow people to follow it but only allow admins to post?

<Loqi>

<puckipedia> mmh. should it be possible to e.g. use a Group as e.g. a Facebook pagPage

<melody> like a broadcast list

<cwebber2> thanks Loqi :P

<beatrix-bitrot> the group could possibly also follow you?

<Loqi> you're welcome

<puckipedia> beatrix-bitrot: yeah, thinking about that. but that means that your posts all arrive into the group's inbox

<beatrix-bitrot> that would be bad

<melody> i think that looks hacky, follow semantics aren't a good fit

<puckipedia> maybe have a `moderators` collection on the group

<puckipedia> and {type: Add, object: user, target: group/moderators}

<melody> groups have membership and access control semantics that don't cleanly match a follow relationship

<puckipedia> or, just {type: Accept, object: user, actor: group}

<cwebber2> for really complex things, eventually https://w3c-ccg.github.io/ld-ocap/ may be a good fit, but I would say not yet ;)

<cwebber2> (particularly for moderation things)

<cwebber2> so someone ( beatrix-bitrot ?) suggested writing this stuff up

<beatrix-bitrot> i asked if it was going to be/needed to be written up

<beatrix-bitrot> i'm trying to determine whether the protocol as it is specified provides enough for us to implement groups

<beatrix-bitrot> or if more protocol needs to happen first

<puckipedia> anyways quick tangent: https://gist.github.com/puckipedia/fcd9c7e12d9d50897b9a16179abbd58a I wrote down a semi-formal thing for my suggestion for JSON-LD sigs

<cwebber2> https://public.etherpad-mozilla.org/p/ap-groups

<melody> anyway the reason I'm being persistent about this is because access control and abuse prevention go hand in hand -- groups could very easily become spam or harassment relays if we don't treat it as more than an afterthought

<beatrix-bitrot> melody that is one of my main concerns

<cwebber2> I actually think AP's notion of ACL is fairly poor... and ACLs are already a fairly poor design

<cwebber2> confused deputy / ambient authority problems, and then you add the "implied by addressing" bit from AP and it's not a great time IMO

<cwebber2> that was part of my motivator for working on https://w3c-ccg.github.io/ld-ocap/ (but there are other motivators)

<melody> i'm using "access control" very generally, substitute a less loaded term

<melody> at your discretion

<cwebber2> :)

<melody> the point is that having open-access forwarding relays that amplify your audience and (if not designed correctly) can circumvent blocking and you have a bad time waiting to happen

<melody> just wanna make sure all the angles are thought through

cwebber2 nods

<beatrix-bitrot> so should groups only forward posts from members?

<melody> arguably that should be up to the group

<beatrix-bitrot> right

<beatrix-bitrot> so it's a software thing rather than a protocol thing

<melody> but clients need to know whether you can post to a group

<beatrix-bitrot> that would be good yes

<melody> so that's a protocol t hing

<beatrix-bitrot> is there room in however we describe the group itself to specify that?

<beatrix-bitrot> whether posting is open or members only or some arbitrary set of allowed people?

<melody> idk, permissions are messy

<beatrix-bitrot> i don't have a very good knowledge of protocol things unfortunately, mostly just mastodon internals

<beatrix-bitrot> and even there i know less than a lot of others

<melody> i have more concerns than i have solutions, and haven't yet written a line of code for my eventual implementation, so you're three steps ahead of me