Re: Thoughts on directions for a rebooted SWICG

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.