High-level Rust library for the Activitypub protocol - GitHub - LemmyNet/activitypub-federation-rust: High-level Rust library for the Activitypub protocol
The library has a nice guide
and two working examples, so I tried the local_federation example. To build the example, you need Rust compiler, cargo package manager, and git:
$ git clone https://github.com/LemmyNet/activitypub-federation-rust
$ cd activitypub-federation-rust
$ cargo run --example local_federation axum
[INFO local_federation] Start with parameter `axum` or `actix-web` to select the webserver
[INFO local_federation::axum::http] Listening with axum on localhost:8001
[INFO local_federation::axum::http] Listening with axum on localhost:8002
[INFO local_federation] Local instances started
[INFO local_federation] Alpha user follows beta user via webfinger
[INFO activitypub_federation::fetch] Fetching remote object http://localhost:8002/.well-known/webfinger?resource=acct:beta@localhost:8002
[INFO activitypub_federation::fetch] Fetching remote object http://localhost:8002/beta
[INFO activitypub_federation::fetch] Fetching remote object http://localhost:8001/alpha
[INFO local_federation] Follow was successful
[INFO local_federation] Beta sends a post to its followers
[INFO local_federation] Alpha received post: Hello world!
[INFO local_federation] Test completed
You may want to use network analizyer (e.g, wireshark) to see how it works under the hood.
I've run the example local federation code, but I didn't know to use a network analyzer. Thanks! That should help a lot.
If I happen to have some webhosting, domain name, and valid SSL cert, is there any harm in using that to learn live in-practice stuff with? Pretty sure I read somewhere about not doing that so as not to clutter up the fediverse with test posts or something.
Hosting Lemmy instances on a localhost has these advantages: 1) no TLS required (right?), 2) can sniff the network traffic between the instances, 3) can change codes and settings of the all instances without asking to anyone, and more importantly, 4) no maintance cost. But if someone want to learn Web app deployment (TLS certs, hosting, etc.), your option would be a good idea.
But if someone want to learn Web app deployment (TLS certs, hosting, etc.), your option would be a good idea.
I think for some they'd just get a real kick out of seeing their own thing federate. Actually "seeing it" happen might be motivation enough. Which I get completely, so I figure facilitating that for people, as well as running through the other web app stuff as you say (which again is worth "seeing happen" if you haven't gone through it before).
If I happen to have some webhosting, domain name, and valid SSL cert, is there any harm …
Been wondering the same.
The core devs run some test instances. It may be workable for any test instances we have to federate only with those (which may require the devs adding something to an allowlist or something). Anything we are running can of course federate with each other I suppose. Activity will be limited, but a little network we can poke may be all that’s necessary?
@[email protected] , if you don’t mind me bothering you, would something like this be at all feasible or useful? Otherwise, any thoughts on running test instances for ourselves and the load on the network?