PoC: Mastodon (ActivityPub) Service #1
Description
Summary
We're bringing together some folks who have expressed an interested in running a high-quality, performant & reliable Mastodon (ActivityPub) service, with particular attention paid to:
- Long term sustainability (costs, operations, etc)
- Servicing (at first, but not limited to) the Asia Pacific (APAC) region. One person whos interested, would like to service Malaysia communities, and an APAC presence supports this nicely.
- For Technology / Open Source and adjacent communities.
Strategic / Other Considerations/Targets:
We'd also like to, as long-term targets, think about and look toward, using this (poc, service) as an opportunity to:
- Use and improve existing Open Source projects as a first option
- Level up FreeBSD support for the OSS projects this PoC uses
- Think about and work toward what a geographically distributed architecture might look like, both in terms of performance, but also reliability and servicing other regions. Look for any of this kind of possibility when evaluating implementations, or things that explicitly might prevent or preclude the possibility.
For this PoC, we'll need to:
Determine High-Level Selection Criteria
Possible criteria (TBD)
- Looks/feels "productive"
- Permissive license (BSD/MIT/etc over AGPL/GPL)
- "Popular" (easy to find devs for)
- Well maintained (frequent releases, open project, good feels)
- Opportunity to improve FreeBSD stack support, have a package, etc.
- Long-term viability/feasibility, maturity, etc
- "Scale-ability" (distributed, geo, storage (s3, etc) separation, caching, etc)
- Minimal "risks" (red flags, complexity, etc)
- Uses "frameworks" (how much is 'custom')
Evaluate multiple ActivityPub (with Mastodon Integration) Implementations
Should take the form of a product / feature matrix with additional notes
- Features, including, multi-tenancy / multi-domain (now or future)
- Architecture, particularly with respect to scalability options (now or future), such as:
- Independent/External Storage (S3, etc)
- Database Scaling options (distributed, sharding, read-replicas, etc)
ActivityPub Server List (Potential Candidates)
Ruby
- Mastodon (Ruby on Rails (AGPLv3))
- Official/reference implementation
Rust
- Tranquility (MIT)
- MicroStatus (ISC)
- Plume (AGPL)
Golang
- GotoSocial (AGPL-3.0)
NodeJS
- MissKey-Hub (MIT)
- Pump.IO (APACHE2)
Elixir
- Pleroma (AGPL)
PHP
- Friendica (AGPL)
- GNU Social (AGPL)
- Hubzilla (MIT)
Python
- takahe (BSD3, Django) <-------------- 👀😏😉
- socialhome (AGPL)
- microblog.pub (AGPL)
Probably "No Go" Options
- Kroeg (Rust, MIT, last update 2019)
- microblog.pub (Python, AGPL, last update 2019)
- Go-Fed (Go, BSD3, Looks library only, "apcore" is AGPL)
- Mastodon.py (Python, MIT, API Wrapper, Client only??)
Shortlist implementations based on Criteria above && PoC Deploy
Taking notes as we go.
- jsm@f.o Mastodon (RoR)
- jaunty: Takahe (Django)
- You! Pick an implementation, PoC and take notes
Determine / Hash-out human expertise / roles & responsibilities
- Experience, background, skills, languages, what people want to work on
Eg:
- koobs: infra, ops, django (python/pg) & php stacks @ scale
- tehpeh: RoR experience
Notes & Resources
Long-term scaling (costs/engineering) is a big challenge in this space for a 'forever growing' workload like social media, so:
We'd like to partner with existing service providers (iaas, compute, storage) where-ever possible, and where there is a mutually beneficial relationship to be had or created. If and where we have contacts/resources in this space, these would be good to know
ActivityPub Resources
- ActivityPub.rocks: Implementation Reports
- Newer list of ActivityPub based projects
- Older list of ActivityPub based projects