twit VS fedbox

Which processes up to 8k requests at a time, waiting up to 10 ms for a batch.

Similar techniques should work on read batching, but I haven't tried that. You can also speed that up some more with the COPY protocol, but IIRC you need to be more careful about escaping/SQL injection.

On my 6 year old mid-range desktop (this CPU[1] and this disk[2]) this program can process ~30k `create`s per second. For about $1500, I could buy a new computer with a Ryzen 9 7950 with 4x the core count/8x the thread count and 2x the single-threaded performance, so around ~10x more processing power, 128 GB of RAM, and a Samsung 980 Pro SSD, which can do 1M Write IOPS (25x more than my SSD) or 5GB/s sequential writes (10x more). So a $1500 computer with a single disk should be able to do around 300k/s. PCIe gen 5 is now coming out, which will allow for another doubling of disk performance.

128GB of RAM means you can keep at least 100M rows worth of index in memory. It's not that expensive (under $10k) to build a server with 1TB of RAM.

Totally feasible for a hobbyist to do without tons of tricky optimization; people spend $20k on a jetski or $80k on a truck. Like I said, the most expensive part is going to be the storage, but you could do something like only store the most recent 1000 tweets per person, and charge $10 to bump that up to the most recent 10 million tweets or something. You'd come out at a substantial profit with that model if you got a few thousand takers. Similarly you could charge to let someone follow more than a few thousand people so you could pay for a read replica or two.

[0] https://github.com/ndriscoll/twit/commit/19b245677b978b42a6f...

[1] https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6600K...

[2] https://www.disctech.com/SanDisk-SDSSDHP-256G-256GB-SATA-SSD

If you're interested in an ActivityPub that works like that, I work on one called FedBOX[1]. It doesn't have clients at the moment, but that's how I planned to have it used.

https://github.com/go-ap/fedbox

Well, there is one already as the reference implementation for a suite of libraries I wrote. You can find it at https://github.com/go-ap/fedbox. (Contributions welcome)

Also my project, mentioned elsewhere in the thread: https://github.com/go-ap/fedbox, supports filesystem storage directly.

Hi, I'm the developer of go-ap. Which parts of it are giving you trouble? I'm always open to answer questions to the project's mailing list: https://lists.sr.ht/~mariusor/activitypub-go

There is a rather hidden wiki that has some more information than strictly the comments in the code: https://man.sr.ht/~mariusor/go-activitypub/

If you are looking for examples, there is a reference server at https://github.com/go-ap/fedbox

There is a Go implementation of a generic ActivityPub service. I am actively working on it as we speak: https://github.com/go-ap/fedbox. (You can see a demo instance of it at https://federated.id)

That's pretty cool actually. I've been tossing around the idea of a federating forum style UX that uses ActivityPub, and I figured it would be easy using something like this https://github.com/go-ap/fedbox

I don't know how many generic AP backend servers are out there, but it looks like Lemmy is becoming one. I hope they keep with the AP spec and allow any functionality in addition to it to be modular.

> What we really need in this landscape is dead simple services.

I'm working on exactly that: a service that acts as an ActivityPub server (code[1], example[2], example application running on top of it[3]) for users in the form of a static binary. It supports multiple storage backends that can be selected individually or all together at build time and it can be extended to many more.

[1] https://github.com/go-ap/fedbox

[2] https://federated.id

[3] https://littr.me