Re: Thoughts on directions for a rebooted SWICG

Hi SWICG!

Thanks Erin, for starting this thread.

Some of you know me, many of you don’t.

I founded Mosaic Foundation <https://www.mosaic.social/> in the Spring of
this year, with the mission to foster digital infrastructure for a new era
of democratic societies. Prior to that I worked in the Self Sovereign
Identity space for six years doing business development. I have had a
passion for decentralized social media since before the Diaspora
Kickstarter campaign.

We have a real shot at fostering new more egalitarian and democratic forms
of human coordination and my hope is that the Fediverse can be digital
infrastructure for that potential future. I’d like to see the Fediverse be
something for the masses, for each person and group to build community in
whatever way they choose.

Some of the topics I am interested in discussing are:

   1.

   Performance: what can be done about the performance issues of some of
   the larger instances, like Mastodon.social. Are there ways to ensure
   performance across the Fediverse? This seems critical for high bandwidth
   cases like video streaming.
   2.

   Easy profile and data portability: can we make it easier to backup one’s
   social data (e.g. posts) and migrate to a new server without data loss or
   loss of social connection?
   3.

   Single-user instances: is it feasible from a technological and economic
   efficiency standpoint to enable single-user instances in the Fediverse?
   4.

   Spaces/Groups/Communities: how do we enable independent spaces, groups,
   or communities in the Fediverse such that people can join one or more
   private or public groups, receive posts, and make comments, without having
   to create a new account for each group they join?


I wonder if anyone is also interested in discussing big picture
philosophical, economic, and social issues related to growing the Fediverse
into an ecosystem that minimizes harm and maximizes prosocial outcomes.

Like

Social harms of existing social media: how do we correct for the harms that
the predominant social media paradigm produces?

   1.

   Ledger of Harms as defined by the Center for Humane Technology,
   https://ledger.humanetech.com/
   1.

      Attention Hijacking: Optimized for time on site, wastes time
      2.

      Social Sensemaking: Misinformation / Disinformation
      3.

      Democracy and Elections: Powerful Propaganda, Lack of Transparency
      4.

      Mental Health: Addiction, stress, loneliness
      5.

      Memory and Cognition: Reduces memory and focus
      6.

      Childhood Development: Developmental Delays, Suicide


Enough from me!

I am very much looking forward to the SWICG starting back up and
collaborating with you all. :)

Kind Regards,

Adam Lake


On Thu, Dec 1, 2022 at 2:24 PM Aaron Gray <aaronngray@gmail.com> wrote:

> a) I read VM code bases, V8 is far far more optimized than Ruby's
> b) Installing Mastodon overheated my BananaPi M3 and shutdown it down !
>
> On Thu, 1 Dec 2022 at 19:04, Christopher Guess <cguess@gmail.com> wrote:
>
>> Aaron,
>>
>> Do you have any numbers for the claim that ruby is ineffecient compared
>> to JS? I’ve never seen it claim to be more power effecient (and on a
>> Mastodon server speed should probably be preferred over power effeciency).
>>
>> -Christopher Guess
>> cguess@gmail.com
>> US/WhatsApp/Signal: +1 262.893.1037
>> PGP: AAE7 5171 0D81 B45B – https://keybase.io/cguess
>>
>> On Thursday, Dec 01, 2022 at 1:31 PM, Aaron Gray <aaronngray@gmail.com>
>> wrote:
>> The issue I have with Mastodon is its server is written in Ruby and is
>> very inefficient. And as a result it is not green energywise.
>>
>> I am looking at putting together first a Node.js implementation similar
>> to Mastodon as a reference implementation to work from as I find Rails very
>> strange (also) then look at a full RDF based implementation, followed by an
>> implementation in a static language like Rust or C++.
>>
>> I am gemming up on all the standards involved first and having a look at
>> some of the existing implementations that we do have.
>> I am compiling a list of links for the whole area too as well which I
>> will probably put on GitHub.
>> There are some existing resource lists :-
>> https://socialhub.activitypub.rocks/ https://activitypub.rocks/
>> And a page for implementers :-
>> https://socialhub.activitypub.rocks/pub/guide-for-new-activitypub-implementers
>> Activity Streams seems to be the actual data side of the ActivityPub
>> protocol used for communicating between "mailboxes" :-
>> https://www.w3.org/TR/activitystreams-core/
>>
>> It would be nice to have protocol implementations in all the main
>> languages TypeScript, JavaScript, Java, Rust, C++, Python, ..., adhering to
>> a standard API structure isomorphic to the problem domain / specs, and to
>> have UML based documentation
>> With ActivityStreams like db and db adapters for main dbs like GraphDB
>> and more traditional DB's like PostgresSQL.
>> So ActivityStreams as the data model, and ActivityPub as the
>> communications protocol running over HTTP(S)
>>
>> Regards,
>>
>> Aaron
>>
>> On Wed, 30 Nov 2022 at 22:12, 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
>>>
>>
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and Computer Scientist.
>>
>>
>
> --
> Aaron Gray
>
> Independent Open Source Software Engineer, Computer Language Researcher,
> Information Theorist, and Computer Scientist.
>
>