I’m very excited about the potential of this one. Andrew (who is building it) created the Python ASGI spec for building interoperable async Python web applications, and has been the driving force behind the addition of async to Django: https://www.aeracode.org/2018/06/04/django-async-roadmap/
ActivityPub is the perfect application for async because of all of the outbound HTTP traffic it uses.
As such it’s very exciting to see how Andrew goes about architecting a Django application to handle that.
But, if I may digress a little, why does everyone insist on implementing applications instead of writing robust libraries that everyone can use?
There must be a 10:1 ratio for every programming language, even in one like python where the dynamic aspect of the language would make implementing the Json-LD logic simple. Sigh.
Takahē is only about a week old at this point. I wouldn’t trust a library for something like this that only had a week of development and hadn’t yet been used in a production application!
I’m actually hoping to use some code from Takahē in my own projects (the signing code specifically) - I plan to volunteer to help extract it out into a library when it’s ready.
That’s good to hear. But signing is very small part of an ActivityPub server. :P (and honestly I can’t believe python doesn’t already have a HTTP signatures library)
Even more so considering that Epicyon (another lightweight python AP server) has been around for years and could use help fixing bugs and adding features. Ah well, people will work on what they want to work on. But I personally wish for more collaboration.
Because ActivityPub is probably implicit. However, it’s not really a general client protocol AFAIK, and there are plenty of clients that support Mastodon’s protocol.
It is though. ActivityPub has two sections, the client to server (C2S) one and the server to server (S2S) one. Historically services have mostly implemented the later but avoided the former for various reasons: either claiming that it’s a little under specified (which it is) or that they had their own client APIs by the time ActivityPub was usable (as is the case for Mastodon for example).
I am working on a suite of libraries (for Go) and a generic ActivityPub server that implements both.
Since Mastodon uses ActivityPub for server-to-server communication only, nearly all the clients created use the Mastodon API for client-to-server communications. A very small minority support both AP C2S and Mastodon’s API but it’s nearly a lost cause at this point; Mastodon’s API is the de-facto standard. If you want good client support, it’s the only way.
“Become an expert in iOS, Android, Electron, native Windows apps, etc so you can add C2S support to the existing apps” isn’t really feasible for most people. Technically it is “just more work” but it’s unrealistic.
This is quite exciting. There is an open issue for Mastodon to allow for multi tenancy/virtual hosting, but it has been open for a long time. The rationale that you can own your online identity is intriguing and along the lines of IndieWeb.
Consider a use case where you got a technical friend to be responsible for your ActivityPub instance, but you bring your own domain. If the friend at some point no longer wishes to maintain the instance, you could seamlessly take your identity to another instance.
While Mastodon’s memory-hungry nature makes it a bad fit for this, you can already do this fairly easy by plopping an nginx load balancer in front of a handful of GoToSocial instances. Each GtS only takes about 100MB of RAM. Keeping everything in the same process would be a little more efficient, but you can already fit scores of domains on a single machine with half the memory footprint of Mastodon.
I’m very excited about the potential of this one. Andrew (who is building it) created the Python ASGI spec for building interoperable async Python web applications, and has been the driving force behind the addition of async to Django: https://www.aeracode.org/2018/06/04/django-async-roadmap/
ActivityPub is the perfect application for async because of all of the outbound HTTP traffic it uses.
As such it’s very exciting to see how Andrew goes about architecting a Django application to handle that.
I didn’t know of this one thanx for posting.
But, if I may digress a little, why does everyone insist on implementing applications instead of writing robust libraries that everyone can use?
There must be a 10:1 ratio for every programming language, even in one like python where the dynamic aspect of the language would make implementing the Json-LD logic simple. Sigh.
Takahē is only about a week old at this point. I wouldn’t trust a library for something like this that only had a week of development and hadn’t yet been used in a production application!
I’m actually hoping to use some code from Takahē in my own projects (the signing code specifically) - I plan to volunteer to help extract it out into a library when it’s ready.
That’s good to hear. But signing is very small part of an ActivityPub server. :P (and honestly I can’t believe python doesn’t already have a HTTP signatures library)
Even more so considering that Epicyon (another lightweight python AP server) has been around for years and could use help fixing bugs and adding features. Ah well, people will work on what they want to work on. But I personally wish for more collaboration.
https://epicyon.net/
surprising their 1.0 proposed feature list has Mastodon API support. Why not use the ActivityPub protocol?
Because ActivityPub is probably implicit. However, it’s not really a general client protocol AFAIK, and there are plenty of clients that support Mastodon’s protocol.
It is though. ActivityPub has two sections, the client to server (C2S) one and the server to server (S2S) one. Historically services have mostly implemented the later but avoided the former for various reasons: either claiming that it’s a little under specified (which it is) or that they had their own client APIs by the time ActivityPub was usable (as is the case for Mastodon for example).
I am working on a suite of libraries (for Go) and a generic ActivityPub server that implements both.
Since Mastodon uses ActivityPub for server-to-server communication only, nearly all the clients created use the Mastodon API for client-to-server communications. A very small minority support both AP C2S and Mastodon’s API but it’s nearly a lost cause at this point; Mastodon’s API is the de-facto standard. If you want good client support, it’s the only way.
I disagree. It just requires more work.
“Become an expert in iOS, Android, Electron, native Windows apps, etc so you can add C2S support to the existing apps” isn’t really feasible for most people. Technically it is “just more work” but it’s unrealistic.
This is quite exciting. There is an open issue for Mastodon to allow for multi tenancy/virtual hosting, but it has been open for a long time. The rationale that you can own your online identity is intriguing and along the lines of IndieWeb.
Consider a use case where you got a technical friend to be responsible for your ActivityPub instance, but you bring your own domain. If the friend at some point no longer wishes to maintain the instance, you could seamlessly take your identity to another instance.
While Mastodon’s memory-hungry nature makes it a bad fit for this, you can already do this fairly easy by plopping an nginx load balancer in front of a handful of GoToSocial instances. Each GtS only takes about 100MB of RAM. Keeping everything in the same process would be a little more efficient, but you can already fit scores of domains on a single machine with half the memory footprint of Mastodon.
This is the same project as described in https://lobste.rs/s/qingh6/efficient_activitypub_server_for_small so this submission can be folded into that. @pushcx