helgekrueger / bovine Goto Github PK

The goal of this issue is to create a better separation between "ActivityPub Server", i.e. bovine, and "ActivityPub Client, e.g. Mastodon. This will be done by "forwarding" activities to the "ActivityPub Client", so it can process the activity through its internal ActivityPub Server.

Goal

If one can succesfully implemented this, one should be able to separate the ActivityPub Actors from the user accounts on Mastodon. This means one can create a setup where a Pixelfed, Mastodon account result in the same Fediverse handle, e.g. [email protected]. Similarly, this Fediverse handle can then be used to send encrypted messages ...

First Implementation

• The script in https://github.com/HelgeKrueger/bovine/blob/dev/bovine_core/examples/mastodon_bridge.py uses the event_source provided by Bovine to forward all incoming traffic to Mastodon. It shows up on the federated timeline.
• The commit HelgeKrueger/mastodon@d50e57c disables HTTP Signature checking

Why I stopped

Running Mastodon in the vagrant box generated a lot of CPU load / network traffic. This seemed unnecessary. I lack the knowledge of Mastodon to fix this.

The posts appearing in the federated timeline do not create the experience, I expect ... So it was not fun to work on. I don't think getting the posts into the home screen would help, as I'm used to seeing full conversations by now.

There should be a way for an ActivityPub Client to authenticate against Bovine and request access to an Actor's data. Something like OAuth is probably necessary.

The package bovine_process handles the task a server has to do to satisfy the requirements set out in Sections 6 and 7 of https://www.w3.org/TR/activitypub/. The pattern should be pretty straightforward: One method for each Subsection.

The entire processing chain is defined in the variables default_inbox_process and default_outbox_process in bovine_process.process (I might want to move this to bovine_process).

Implementing the methods themselves should be "easy". Thinking of appropriate test cases will probably not be.

Issue if bovine is restarted and oven (https://codeberg.org/helge/oxen/src/branch/main/event_loop.py) is not, oxen will not reconnect.

It should be possible to adapt the tests in /tests to do actual HTTP. A few things will be necessary for this:

• Start bovine_blog as an actual server best reachable through a domain name one can configure. So http://bovine.local/ would work as a domain.
• Probably even start an external instance to do the posting from, so something like http://bovine.external/activitypub/user#main-key is resolvable. Otherwise it might be hard to test stuff like HTTP Signatures
• Rewrite /tests/utils/blog_test_env in order to use this setup

It should not be necessary to actually touch the tests. At least once bovine 0.1.0 is released.

The main goal of this would be to be able to run this test suite against any valid ActivityPub implementation (it replaces bovine.local) and the suite should pass.

Of course, this assumes that bovine flavored Client To Server is implemented. E.g. the eventSource test only works if an eventSource is implemented.

The setup:

• Home server, where the main account lives, e.g. [email protected]
• Proxy server, where this example lives, e.g. [email protected]
• The Fediverse

This example does:

• Activity from Home:
  • Forwards to the Fediverse as own activity
• Activity from Fediverse
  • Filters if activity contains more than 100 characters, if yes discards
  • Forwards to Home

This should demonstrate how bovine can be used for things beyong "yay, it's the best Fediverse server in my humble opinion".

Necessary thinking

• How forwarded and rewritten activities fit into ActivityPub specs / FEPs / Json-LD? This means how to inform [email protected] that the activity was forwarded from [email protected]
• In order to be an effective demonstration https://mymath.rocks/ needs to display replies. Do I want that?
• Think about if this is easy to abuse, how is this different than https://gitea.moe/lamp/activitypub-proxy

A common complaint about the FediVerse are missing replies. Here is how to implement a "reply fetcher" in an ActivityPub Client. Usage will require a server supporting ActivityPub Client 2 Server.

Implementation Strategy

Here's how to implement this:

from bovine.activitypub import actor_from_file
actor = actor_from_file('you.toml', aiohttp.ClientSession())

# the following is awkward and should be fixed
response = await actor.proxy_element(original_url)
element = json.loads(await response.text)

The element then has a replies collection. Fetch it ... getting it with actor.get_ordered_collection might be currently possible. As the credentials used to connect to the Bovine ActivityPub Server are the same as used to other hosts. However, it would be cleaner to also proxy the elements.

Then repeat this for all the replies.

Once this is done build a display. It might be possible to reuse Buffalo in particular:
https://codeberg.org/helge/Buffalo/src/branch/main/src/components/timeline/DisplayConversation.js

Implement automatic rotation of the public key pair used for ActivityPub Server 2 Server communication after say a month:

• Investigate best practices on the period to update a keypair
• Ensure updating the key pair doesn't create problems when communicating with other FediVerse services
• Investigate if there is a way to inform other services about an updated keypair. Otherwise consider writing a FEP

Automatic rotation will probably implemented as part of Moo-Auth-1 as the key is part of the header there, rotation should be unproblematic.

User should be able to

• Set his actor name / summary. Possibly change his preferredUsername. Not sure if this is compatible with Mastodon and company.
• Upload new public keys

This could be done for example through a web form. Also disabling the account might be a possibility to add.

Maybe also consider some type of admin role.