Activitypub support (read-only so far)

[aartaka]

This introduces ActivityPub support, allowing to read content from Mastodon, Plume, Lemmy and other federated social networks -- all in the same Nyxt-native configurable interface.

What's New

• An internal library for JSON-LD "parsing" (rather, guessing the contents of it) and "unparsing"/serialization. See parse-object and unparse-object.
  • This should be abstracted to a separate repository at some point in time...
  • Also, there are fetch-object and send-object that allow getting/sending the objects from/to somewhere else.
• An ap: scheme allowing one to look at ActivityPub-enabled pages.
  • nyxt/activitypub-mode:object->html generic function is responsible for HTML rendering of those, and is replaceable/extensible, much like any other generic function.
• nyxt/activitypub-mode:activitypub-mode to enable on ap: pages for additional functions.
• A set of helper functions (name*, url*, author*, published* etc.) for ActivityPub page information extraction.
• activitypub-login to authorize Nyxt acessing profile data.
  • It's useless for e.g. Mastodon without HTTP signatures (see Things to Discuss).

Things to Discuss

• Mastodon and, quite likely, some other federated social networks require HTTP signatures. For that, we need to use some cryptography library and be smart about encrypting parts of our requests. Ironclad?
  • This lack of signatures is what stops us from being able to create content on ActivityPub. Once we have this -- we also have content creation, following other Fediverse people, saving things to collections -- everything that ActivityPub allows!
• Does the interface look fine? You can check profile rendering by going to ap:ephemeral.glitch.social/@aartaka and looking at profiles of the ones I follow :)
  • More testing with other platforms is welcome! Peertube is not yet supported, for example, as it has lots of URLs for every specific video, and out algorithm gets confused for which one to pick.
• I'm using a newly intoruced .card CSS class for posted content styling. Should we abstract it to buffer? Somewhere else? I mean, we're getting dangerously close to having a kind of UI system, yet the one scattered all around the modes and duplicating/repeating itself terribly.
• I've added the ap: scheme to the list of internal schemes so that we can have lisp: URLs and interactive actions on ActivityPub-enabled pages. These pages, however, can contain arbitrary web content, including easily exploitable HTML+JS pages! This is dangerous ヽ(ﾟДﾟ)ﾉ

References

• ActivityPub standard.
• ActivityStreams, and underlying JSON-LD-based data trasfer format
• ActivityStreams Vocabulary, an index of ActivityStreams (and, by extension, ActivityPub) entities.
• Mastodon Docs.

Does this look sane? Again, testing is much welcome :)

[Ambrevar]

Wow, this is MASSIVE! Your productivity keeps astounding me, Artyom! :D

I'll review this more in depth later. Maybe we keep this for after 3.0?

[aartaka]

Wow, this is MASSIVE! Your productivity keeps astounding me, Artyom! :D

Yeah, I'm surprised at myself at times too :D

I'll review this more in depth later. Maybe we keep this for after 3.0?

We're not in hurry -- the planned deadline for this feature is autumn, as far as I remember :)

[aartaka]

@Ambrevar, I cannot make much sense out of Mactodon security documentation and http-signature standard, as both of those seem to omit lots of practical details. Things that I, in particular, cannot untangle, are:

• What's the signing algorithm Mastodon uses? The JSON that it sends mentions ed25519 encryption, while server code seems to rely on OpenSS and RSA. I'm lost ｜−・;）
• How do we sign messages with public keys using Ironclad? All of ironclad:sign-message methods specialize against private keys, and it kinda makes sense... But Mastodon docs say that one needs to sign the message with the public key. What the Hell (>_<)

Not requiring you to dig into that instead of myself (I'll continue bumping my head agains the scarse Mastodon docs), but I'll appreciate it if you have any pointers on those :)

[Ambrevar]

Will check it out when I'm done with #2536.

[aartaka]

Okay, it seems that none of the popular ActivityPub-enabled social networks support all of:

• Outbox posting.
• Posting with ActivityPub API.
• Posting unencrypted content.

Which means that none of those can be said to support pure ActivityPub content posting.

Does that make this implementation good enough in that it supports reading ActivityPub-enabled pages, and posting to ActivityPub-enabled endpoints (of which there are not that many, if any)?

I'd be glad to be proven wrong and shown a social network that allows posting things with ActivityPub API! Anyone?

[aartaka]

If the inability to post content is the outside limitation that we have to live with, then my plan is:

• Turn as much methods of nyxt/activitypub-mode into the ones dispatching over the instance-type, so that we can add instance-specific hacks for posting/fetching content.
• Abstract all the JSON-LD and ActivityStreams part of nyxt/activitypub-mode into a separate library (nactivitypub?)
  • Look at the JSON-LD standard and parse it a bit more rigorously.
• Polish the display for things.
• ... and then we can merge, I guess?

[Ambrevar]

Agreed with all points!

The readme of the nactivitypub library (better name?) should include a disclaimer on the limitations.

[aartaka]

So, shall we rebase and merge this now that it's more or less stable functionality-wise? I'd enjoy having NJSON used all over Nyxt, but don't want to interfere with this PR.