Re: Thoughts on directions for a rebooted SWICG

Hi Erin,

This is a great start to the discussion, and I don't have any answers :-)

A thought tho: With the current user increase, a lot of conversations about
these topics are happening in many places; blogs, Toot threads, etc. Would
it be good to have a way to capture links to some of these, so that wider
views are considered? Or maybe even put together a special conversation
between instance admins to hear their views?

James



On Wed, Nov 30, 2022 at 10:12 PM Erin Shepherd <erin.shepherd@e43.eu> wrote:

> Eight (!) years ago, I kicked off what became *AcitvityPub* with an
> e-mail to the SocialWG mailing lists linking to a draft of a protocol I
> named *ActivityPump*; I hoped but never imagined it would end up being
> quite so influential.
>
> It's been nearly four years since the ActivityPub specification was
> published, and never has it felt felt more urgent that we find a way to
> revisit aspects of the standard *together*. None of what follows is in
> any way gospel, these are just my thoughts; but I feel one big thing we've
> been lacking is direction and this is an attempt to give that
>
> --
>
> The challenge, as I see it, with developing anything involved in the
> social web, has always been that everyone's developing their own thing.
> That's really exciting, and it makes the ecosystem incredibly vibrant, but
> it's also quite troublesome, because you end up with 15 people working on
> 15 different things, rather than working towards a cohesive whole. The
> ecosystem and the network have suffered from this; I feel like one of the
> reasons things never really got off of the ground here after the SocialWG
> closed is that there was no obvious direction.
>
> So I would like to suggest that we pick *themes* to work on - one
> initially, with scope to add more as those are established. Perhaps these
> might eventualy feed into the charter for any future ActivityPub WG. We
> should, in general, try and focus on areas causing user issues or friction
> in the network today.
>
> I think there's a general sentiment across the fediverse that our biggest
> problems are to do with inadequite tools to handle *moderation and
> harassment*. There's a mix of implementation improvements and protocol
> improvements that need to be made in this area, but I think it's important
> that we do the protocol development *in particular* outside the scope of
> any single project because it's the sort of thing which is likely to become
> a mandatory feature.
>
> Some particular sub-areas of focus that I can think of:
>
>    1. *Spam Filtering/Sockpuppet Prevention*
>    Or: how to stop people from setting up new servers to bypass your
>    blocks (without caving and resorting to allow-list federation)
>
>    I made a post about this yesterday
>    <https://blog.erinshepherd.net/2022/11/a-better-moderation-system-is-possible-for-the-social-web/>
>
>    This one's a relatively complex addition, but I think it's vital.
>    2.
> *Indirect Harrassment via Replies *Presently, threads are "backwards
>    authenticated" via the *inReplyTo* field from the comment to the
>    parent, but there's no forward authentication from parent to comment. Even
>    if I block you, it's possible for you to reply to my posts, and while my
>    server won't show your replies when looking at my post, other servers which
>    saw your replies will.
>
>    I don't think allowing people to make "unapproved" replies is bad; but
>    I do think that when looking at a post, implementations *should*
>    de-prioritise such replies (think of Twitter's "more replies have been
>    hidden" feature, which normally hides a bunch of cryptocurrency spammers)
>
>    I think this is a relatively straightforward protocol change,
>    involving adding a way to indicate a post is in "approved replies" mode,
>    and distributing those approvals. (I think Hubzilla has already implemented
>    something vaguely - but not completely - along these lines)
>    3.
> *Better tools for moderators *This is perhaps the least well defined
>    point (and the one which, in some ways, requires the most implementer
>    buy-in), but I really think we need to specify both the existing reporting
>    protocol, and extend it to (a) allow withdrawing reports and (b) add
>    coments, so server moderators can communicate with each other "in band".
>
> I don't think this is the only topic area worthy of discussion, but I
> think it's by far the most vital. There are other areas I see as very
> important long term (e.g. codifying a way to move accounts without the
> cooperation of the server you're moving away from, simplifying the
> cross-server follow flow, and *eventually* supporting nomadic
> identities), but I think the solutions to those are less well defined, and
> the need is less pressing.
>
> I'm very curious to see the group's thoughts.
>
> (One other thing I think would be a *good* thing to do is to revise the
> AP spec and explicitly document the holes we left because we couldn't find
> agreement with actual practice; but that would be a task for any
> ActivityPub WG that is formed, which I would support)
>
> -- Erin
>