- From: Aaron Gray <aaronngray@gmail.com>
- Date: Fri, 2 Dec 2022 08:14:09 +0000
- To: Benson Muite <benson_muite@emailplus.org>
- Cc: public-swicg@w3.org, Erin Shepherd <erin.shepherd@e43.eu>, Christopher Guess <cguess@gmail.com>
- Message-ID: <CAKXmGHCg5bxx-+QgrJ9sMDyr9fb_uTz3zwp0YBf28QeLjajZ-Q@mail.gmail.com>
On Fri, 2 Dec 2022 at 06:23, Benson Muite <benson_muite@emailplus.org> wrote: > It is possible to write efficient Ruby, but efficiency has probably not > been the focus for Mastodon, developer productivity has likely been more > important. > > One might also consider: > * PHP - some activity pub implementations in this that could be extended) > Is an interpreted language > * Go - relatively light resource use > Go is a static compiled language, but is not very efficient (possibly with or without use of its runtime coroutines for piping) * Kotlin - may be helpful for mobile clients, but can also be used for > server code > Kotlin is JVM based, its a very good language, but again its running on a VM, but it is relatively efficient, but not to the degree that compiled languages like C, C++ or Rust are|) Apart from Java, JavaScript VM's are the most efficient VM's of all the VM's. See :- https://haslab.github.io/SAFER/scp21.pdf Aaron > Other than moderation, one issue might be information credibility. On > centralized platforms, it is possible to monitor fast spreading > information and if it is not credible and can cause harm, counter the > information and point out why it is not credible. Allowing for services > that check for false information can be helpful. > On 12/1/22 22:23, Aaron Gray 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 > > <mailto: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 > > <https://keybase.io/cguess> > > > > On Thursday, Dec 01, 2022 at 1:31 PM, Aaron Gray > > <aaronngray@gmail.com <mailto: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://socialhub.activitypub.rocks/> > > https://activitypub.rocks/ <https://activitypub.rocks/> > > And a page for implementers :- > > > https://socialhub.activitypub.rocks/pub/guide-for-new-activitypub-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/ > > <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 <mailto: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. > > > > -- Aaron Gray Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and Computer Scientist.
Received on Friday, 2 December 2022 08:14:35 UTC