- From: Dmitri Zagidulin <dzagidulin@gmail.com>
- Date: Thu, 1 Dec 2022 13:39:01 -0500
- To: aaronngray@gmail.com, public-swicg@w3.org
- Cc: Erin Shepherd <erin.shepherd@e43.eu>
- Message-ID: <CANnQ-L7DH4c8ZiiqKaE4=7-v=fmghhvbap1J4UVfo5JrxmEYhg@mail.gmail.com>
Hi Aaron, In case you find it helpful, in developing a Node.js server implementation -- there are several good TypeScript implementation, notably CalcKey https://codeberg.org/thatonecalculator/calckey (fork of Misskey). I also find that the https://github.com/immers-space/activitypub-express repo is really helpful, for plain JS. On Thu, Dec 1, 2022 at 1:32 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. > >
Received on Thursday, 1 December 2022 18:39:32 UTC