@ben How is this proposal different from a regular ActivityPub server that also implements the AP C-2-S protocol? I believe such things exist today (although I have no first-hand experience myself).
@J12t@ben If an existing thing meets the need for a service to make life radically easier for would-be AP devs then let's promote it.
Otherwise do this and promote it.
One way or another, there's a huge need to lower the activation threshold. Ideally to the level of RSS's almost imperceptible speed bump, but anyway as close to that as possible.
@judell@J12t Right - I haven't seen a server that makes this as simple as possible and also comes with a viable hosted option to get started with. Making this as simple as implementing RSS is explicitly my goal.
@boris@judell@J12t It could indeed. My single-user instance with very little self-stored resources and a tight cache uses upwards of 60GB of media. The footprint is really really heavy!
@ben I’m reminded of things like Auth0 and Clerk for authentication. This could be a way to manage and bootstrap AP for a site with its own dashboard (and maybe even mobile app) separate of your actual site.
I even. Think pricing is per activity pub user. One for free, and then some kind of other cost that scales up to an enterprise level at the high end.
But, yeah. I love it and I need it. I’ve been looking for something that even remotely resembled it.
@ben Any insights on what the underlying architecture of such a system might look like?
A. Superset. Use some strategy (bsky's lexicons?) to express the wide variety of data models + client APIs needed to support the unique needs of each service (Mastodon vs. Pixelfed vs. Lemmy/Kbin vs. Writefreely, etc).
B. Subset. Host a pure account/inbox/outbox paradigm + expose that to the rest of each app via a common REST API so each can build from there.
@ben I would also suggest thinking carefully about the ongoing governance of a cooperative model. It works well but adding customers buying in and not thinking upfront about how to handle say early contributors who then become less active in the future may complicate the ongoing running of a co-op. My advice would be to keep it simple, have a clause to buy back shares from inactive members and not sell shares to customers until you are stable & past the startup phases.
@ben I need to ponder this a bit but I like the idea and general direction. May be useful for some ideas I have that I’m pursuing (which I think are complimentary)
A few thoughts:
think thru the go/no go financial aspects of this and use that to help define the “non traditional funding” options (for example - could this be funded via contract development projects that were going to use the service?)
think about the pricing tiers to support a range of projects before and after launch
@ben very neat. My only detraction from this is that it precludes other #foss projects from implementing first-class #ActivityPub support because of its paid nature (but I 100% understand the need to do so, hosting isn't free!)
Bundling the open source server in with a project also seems like it'd be complicated, so at least for #NodeBB it sounds like we may still have to forge on ahead with our own implementation.
@ben I had found this by chance a few days ago. I found it quite interesting too as a project. So for developers who want to implement an very simple activitpub service for their app. https://github.com/evanp/onepage.pub
@ben super interested in this idea. I get a lot of requests to support services other than Mastodon with @mastowatch and it would basically be impossible without some kind of standardization layer like this.
@ben@tchambers Love this idea. The AP spec is too much to parse. The Mastodon API is tractable but not really extensible on the back end if (say) I wanted to add some side tables to a schema & layer API/UI over the combo. Don’t know that there’s startup $ in just an API without default UI, but would love it if @mastohost offered something like this as hosting plan. An extensible hosting service seems like a better biz proposition.
@ben@tchambers@mastohost I think what I’d like is an “extend-o-don” A mastodon-alike where all 3 of the Schema/API/UI have affordances for extensibility without having to touch the core product. https://labkey.com is designed this way with “modules” that can supply all 3 of these. Question to answer: what’s the equivalent of a pluggable browser extension but for a social media platform?
@markigra@tchambers@mastohost Oh, interesting. I designed Elgg in exactly the way you describe (albeit as an open source social networking platform that predated ActivityPub and therefore didn't support it). I'd been thinking about rebuilding Elgg from scratch using AP, perhaps as a first use of this underlying platform.
@ben@tchambers@mastohost If you are trying to do a startup, a "white label” iOS/Android app might be an interesting option. Or at least an app that supports custom onboarding flow as an easily-added extension category. I would have loved to be to customize onboarding for sciences.social. I think that's something all fedi community platforms should have.
@ben I like the idea.
Do you see it as a sort of IFTTT layer for ActivityPub?
There are all sorts of services which could benefit from "send this to the Fediverse" and "when someone replies to my post do X" type things.
@Edent It definitely could be used that way, and that's probably where a lot of use would lie - as well as the fediverse layer to full new applications all the way up to a Mastodon-compatible community platform.
Add comment