This is a great demo of Cloudflare’s tech stack, but the lock-in factor is strong. You shouldn’t run this unless you’re planning on being a Cloudflare customer forever, because it will never run anywhere else.
Other implementations tend to be huge (Mastodon, Misskey) or tailored to a single kind of activity (Pixelfed, Lemmy) that make them awkward to use as a base for further experimentation. I for one would be very excited to bang on a lightweight-but-somewhat-featureful alternative like this, once suitably modified to run on an open platform.
Generally speaking, I’m very resistant to choosing APIs that are locked to one vendor. Services that are generally available but perhaps simpler to deploy on one vendor’s cloud (see: AWS RDS/Aurora) seem like a pragmatic option for those who already have a relationship with that provider. Workers at least seem headed for some level of standardization, for much the same reason that K8s took off so quickly: everyone wants to get ahead of Amazon’s owning this space like they do object storage and general compute.
If you want small, there’s GotoSocial (single Go binary, SQLite) or Honk (single Go binary, SQLite, no API though). Even more minimally, there’s Epicyon which doesn’t even have a DB, it uses flat files. There’s also another Python one which is strictly single-user but I can’t remember the name of it right now.
It should be noted that GoToSocial is still very much alpha software, and while it does implement most of the mastodon api it isn’t 100% compatible yet.
This is not to be a downer on it, I really like GTS, I’ve contributed to it (and want to contribute more), and follow along their dev chat. It’s still very usable, just don’t expect it to be able to do everything yet.
The only real issues I’ve had with GtS are 1) OOB OAuth doesn’t give you the code on a page, you have to copy it from the URL (ultra minor and most people will never encounter this); 2) friend requests from Honk don’t work because of the “partial actor key” weirdness GtS has BUT this is exacerbated by a weirdness in Honk where it stores the assumed owner of a key instead of the stated owner. Need to dig into this some more before presenting it as a patch / issue tho; and 3) the weird version number breaks a bunch of libraries which use the version number for feature support (looking at you, Mastodon.py!)
Oh and Brutaldon doesn’t work but I can’t get that to work with Akkoma either and I’d be inclined to blame Brutaldon for that rather than GtS.
At least as of version 0.6.0 OOB auth displays it on a page for you, because I was playing around with it and got a nice page that looks like the rest of the UI with the token displayed for me.
The version number thing I think is known, because there’s some client that can’t do any searching because it just assumes because it’s low it uses the old mastodon search endpoint. That said I think I agree with their stance that they don’t want to turn the version field into a user-agent string situation. My own thoughts are everybody implementing the mastodon api should probably just add a new “api_version” field or something, which reports the api compatibility, because asking clients to implement logic to determine capabilities based on different server backends feels backwards when your goal is explicitly compatibility with the api.
I’m on v0.6.0 git-36aa685 (Jan 9) and I get a 404 page with the code in the URL for OOB. Just updated to the latest git (v0.6.0 git-132c738) and it’s still a 404 page with the code in the URL. But like I said, this is an ultra-minor issue most people will never experience.
[version number <=> features is nonsense]
Yep, totally agree but it’s going to be a good long while before we get an api_version field (have you seen how long it takes the Mastodon devs to agree on anything?) and we have to deal with these clients now (e.g. I have to hack my Home Assistant’s local copy of Mastodon.py to get notifications out to my GtS instance.)
Well, there’s /api/v1/XYZ and /api/v2/XYZ but that doesn’t really encompass what these libraries are trying to do by checking the version number because they’re trying to avoid calling endpoints that didn’t exist in older Mastodon versions.
e.g., Mastodon.py wraps all of its endpoint methods with stuff like this:
_DICT_VERSION_CARD is 3.2.0 which means that you’ll get an exception if you try to call whatever.status_card(blah) on a server that advertises a version lower than 3.2.0. GotoSocial is currently at v0.6.0 (which breaks the parsing anyway and stops anything from working because v6 isn’t an integer) which would mean that you couldn’t call any endpoints, supported or not.
What they should have done is have a capabilities endpoint which lists what your server can do and let the libraries use that as their guide rather than guesstimating from version numbers. Much like SMTP or IMAP banners. Or use the client-server protocol which is server-agnostic but they’ve been waffling about that since 2019 with no progress…
I don’t think they’ll ever really focus on the C2S AP protocol, it doesn’t have the same features and hacking them on sounds like a ton of work. I do agree that some sort of capabilities endpoint would be really nice.
Also yeah, agreed that trying to get mastodon itself to add api support for it feels like a huge battle, but I feel like if enough of the alternative servers like akkoma and gts agreed on an implementation, and then implemented something like it, it could force mastodon to conform? But that also has its own problems.
At the end of the day I understand why everyone conforms to the mastodon api, but it would be nice if there was some group outside of mastodon and Eugen defining the api spec, with input from the community and developers outside of mastodon, but that’s pie in the sky wistful thinking, and requires a lot of organization from someone, and buy-in from all the other server devs.
Huh, not sure what makes my GTS instance different, but I’m on the release commit, GoToSocial 0.6.0 git-f9e5ec9, and going through the oauth oob flow gave me this after doing my user login (https://imgur.com/sfm19cx), and the URL I used to initiate the flow was https://<my domain>/oauth/authorize?client_id=<app's client id>&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&scope=read
The Images pricing looks like the killer for this. A $5/month, it’s comparable with a cheap VPS (Vultr has some at that price that should be adequate for a small instance). I’m surprised Cloudflare’s pricing doesn’t scale down more: most cloud storage things charge per MiB or similar and scale right down to $0/month when provisioned but not used.
Probably a good thing that there are many alternatives for getting on the Fediverse. Some of those projects will of course wither with time, but hopefully there will still be healthy competition even so.
Conceptually this seems neat, but yeah, strong agree with basically everyone else in this thread: you’re just asking for trouble being locked into cloudflare’s stack.
It’s also kinda fascinating to me that they implemented the mastodon api, and stole (non-derogatory) the frontend, but they pulled out the posting and browsing capabilities from it, even though their api implementation should support it?
This is a great demo of Cloudflare’s tech stack, but the lock-in factor is strong. You shouldn’t run this unless you’re planning on being a Cloudflare customer forever, because it will never run anywhere else.
That’s definitely true today, but I also think this could be an interesting starting point for a Deno-based ActivityPub server:
D1 -> vanilla SQLite (plus Litestream or similar)
Workers K/V -> Redis
Page Functions -> Actual, plain JS functions hosted by Deno (local workers)
Images -> pict-rs (or similar)
Other implementations tend to be huge (Mastodon, Misskey) or tailored to a single kind of activity (Pixelfed, Lemmy) that make them awkward to use as a base for further experimentation. I for one would be very excited to bang on a lightweight-but-somewhat-featureful alternative like this, once suitably modified to run on an open platform.
Generally speaking, I’m very resistant to choosing APIs that are locked to one vendor. Services that are generally available but perhaps simpler to deploy on one vendor’s cloud (see: AWS RDS/Aurora) seem like a pragmatic option for those who already have a relationship with that provider. Workers at least seem headed for some level of standardization, for much the same reason that K8s took off so quickly: everyone wants to get ahead of Amazon’s owning this space like they do object storage and general compute.
If you want small, there’s GotoSocial (single Go binary, SQLite) or Honk (single Go binary, SQLite, no API though). Even more minimally, there’s Epicyon which doesn’t even have a DB, it uses flat files. There’s also another Python one which is strictly single-user but I can’t remember the name of it right now.
There is one—honk(3), albeit a bit unusual.
Fair - I should have been explicit with the “no mastodon-compatible API” since that’s what apps and frontends expect.
It should be noted that GoToSocial is still very much alpha software, and while it does implement most of the mastodon api it isn’t 100% compatible yet.
This is not to be a downer on it, I really like GTS, I’ve contributed to it (and want to contribute more), and follow along their dev chat. It’s still very usable, just don’t expect it to be able to do everything yet.
The only real issues I’ve had with GtS are 1) OOB OAuth doesn’t give you the code on a page, you have to copy it from the URL (ultra minor and most people will never encounter this); 2) friend requests from Honk don’t work because of the “partial actor key” weirdness GtS has BUT this is exacerbated by a weirdness in Honk where it stores the assumed owner of a key instead of the stated owner. Need to dig into this some more before presenting it as a patch / issue tho; and 3) the weird version number breaks a bunch of libraries which use the version number for feature support (looking at you, Mastodon.py!)
Oh and Brutaldon doesn’t work but I can’t get that to work with Akkoma either and I’d be inclined to blame Brutaldon for that rather than GtS.
At least as of version 0.6.0 OOB auth displays it on a page for you, because I was playing around with it and got a nice page that looks like the rest of the UI with the token displayed for me.
The version number thing I think is known, because there’s some client that can’t do any searching because it just assumes because it’s low it uses the old mastodon search endpoint. That said I think I agree with their stance that they don’t want to turn the version field into a user-agent string situation. My own thoughts are everybody implementing the mastodon api should probably just add a new “api_version” field or something, which reports the api compatibility, because asking clients to implement logic to determine capabilities based on different server backends feels backwards when your goal is explicitly compatibility with the api.
I’m on
v0.6.0 git-36aa685(Jan 9) and I get a 404 page with the code in the URL for OOB. Just updated to the latest git (v0.6.0 git-132c738) and it’s still a 404 page with the code in the URL. But like I said, this is an ultra-minor issue most people will never experience.Yep, totally agree but it’s going to be a good long while before we get an
api_versionfield (have you seen how long it takes the Mastodon devs to agree on anything?) and we have to deal with these clients now (e.g. I have to hack my Home Assistant’s local copy of Mastodon.py to get notifications out to my GtS instance.)Maybe I’m missing something but API versioning feels like something you’d want from day 0?
Well, there’s
/api/v1/XYZand/api/v2/XYZbut that doesn’t really encompass what these libraries are trying to do by checking the version number because they’re trying to avoid calling endpoints that didn’t exist in older Mastodon versions.e.g.,
Mastodon.pywraps all of its endpoint methods with stuff like this:_DICT_VERSION_CARDis 3.2.0 which means that you’ll get an exception if you try to callwhatever.status_card(blah)on a server that advertises a version lower than 3.2.0. GotoSocial is currently at v0.6.0 (which breaks the parsing anyway and stops anything from working becausev6isn’t an integer) which would mean that you couldn’t call any endpoints, supported or not.What they should have done is have a capabilities endpoint which lists what your server can do and let the libraries use that as their guide rather than guesstimating from version numbers. Much like SMTP or IMAP banners. Or use the client-server protocol which is server-agnostic but they’ve been waffling about that since 2019 with no progress…
https://github.com/mastodon/mastodon/issues/10520
I don’t think they’ll ever really focus on the C2S AP protocol, it doesn’t have the same features and hacking them on sounds like a ton of work. I do agree that some sort of capabilities endpoint would be really nice.
Also yeah, agreed that trying to get mastodon itself to add api support for it feels like a huge battle, but I feel like if enough of the alternative servers like akkoma and gts agreed on an implementation, and then implemented something like it, it could force mastodon to conform? But that also has its own problems.
At the end of the day I understand why everyone conforms to the mastodon api, but it would be nice if there was some group outside of mastodon and Eugen defining the api spec, with input from the community and developers outside of mastodon, but that’s pie in the sky wistful thinking, and requires a lot of organization from someone, and buy-in from all the other server devs.
Huh, not sure what makes my GTS instance different, but I’m on the release commit,
GoToSocial 0.6.0 git-f9e5ec9, and going through the oauth oob flow gave me this after doing my user login (https://imgur.com/sfm19cx), and the URL I used to initiate the flow washttps://<my domain>/oauth/authorize?client_id=<app's client id>&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&scope=readI shall have to do a clean install and see if there’s some step I’ve missed during the various updates (which it definitely sounds like I have!)
Lets take something libre and lock it into cloudflare. What could possibly go wrong?
This could burn out the free tier almost instantly and create a huge bill for the function workers.
The Images pricing looks like the killer for this. A $5/month, it’s comparable with a cheap VPS (Vultr has some at that price that should be adequate for a small instance). I’m surprised Cloudflare’s pricing doesn’t scale down more: most cloud storage things charge per MiB or similar and scale right down to $0/month when provisioned but not used.
Crazy level of complexity to get that set up and running. Just not going to do that.
Honestly not that much worse than regular Mastodon
Regular Mastodon is already waaaaay too hard to set up and operate. Absolute nightmare compared to GotoSocial, Akkoma, Epicyon, etc.
Probably a good thing that there are many alternatives for getting on the Fediverse. Some of those projects will of course wither with time, but hopefully there will still be healthy competition even so.
Conceptually this seems neat, but yeah, strong agree with basically everyone else in this thread: you’re just asking for trouble being locked into cloudflare’s stack.
It’s also kinda fascinating to me that they implemented the mastodon api, and stole (non-derogatory) the frontend, but they pulled out the posting and browsing capabilities from it, even though their api implementation should support it?
No demo server?
I’m a bit confused about the database part. I thought D1 was limited to 100mb.