Re: Thoughts on directions for a rebooted SWICG

Hi Erin and everyone,

I'm new to this group but not the fediverse, and have been running 
various federated FOSS-y things since approx 2009 :)

For my take, I think a "killer feature" would be improving key exchange 
and verification, and potentially making public keys more easily 
available and more quickly distributed via ActivityPub for applications 
to build features on top of them (e.g. encrypted chat, verified user 
profiles, verified file sharing, maybe even software supply chain).

That is similar to Erin's #1 re: sockpuppets, or at least has 
ramifications there, but is not the same thing.

Cheers,
- Sean

Sean O'Brien
Fellow, Information Society Project at Yale Law School
Founder, Privacy Lab at Yale ISP,https://privacylab.yale.edu



On 11/30/22 17:08, Erin Shepherd 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.erinshepherd.net%2F2022%2F11%2Fa-better-moderation-system-is-possible-for-the-social-web%2F&data=05%7C01%7Csean.obrien%40yale.edu%7Ce4e9c969536e4607063e08dad31fef96%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C638054431380418670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nydDdwu2heDc5wdXHc4%2BxazcRdpxPkblJ3Ch5%2Fbxd%2BI%3D&reserved=0>
>
>     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