In #FedBOX land, I have finally made progress in excising the OAuth2 routing to its own individual service.
Deploying has increased complexity, but it paves the path for replacing our spit and duct-tape user management to something more robust, like #ory#kratos.
Leftovers in FedBOX are the OAuth2 client CRUD operations, soon to be replaced with automated client creation.
Before taking a break from ActivityPub at the start of the year I was working on bringing all storage types for #FedBOX (the generic #ActivityPub service) to better support persistence of collections.
Finally over the past weekend I managed to bring the sqlite backend (the last remaining) from ~180/458 failing integration tests to just 10/458.
It was definitely a journey.
The best part of this is that it paves the way for any #Golang sql.DB compatible database.
@linos my project #FedBOX supports multiple values for the attributedTo property on ActivityPub objects.
The use case this was required for, even though it's not implemented at the moment, was when mods would edit an object that came under scrutiny on the main client that uses FedBOX as a backend, the #brutalinks link aggregator.
Collaborative editing would also work, but there are no clients capable of that at the moment.
I made some more progress on the application I plan to bundle as an admin tool with #FedBOX, the generic #ActivityPub server, and #Oni, the no frills single user instance.
It's called #Motely and it looks like this currently.
If I read between the lines on the software design for #ActivityPub, I don't think there are actually supposed to be servers per se, or more precisely that servers are supposed to be very simple passthroughs that have some forwarding/processing logic?
If so then this makes some sense, since when AP was being written was a big time for BaaS (Backend as a Service; https://en.wikipedia.org/wiki/Backend_as_a_service ) and that influenced a lot of ideas.
@hrefna that's what I tried to do with #FedBOX, sadly to integrate it with the (mastodon centric) wider fediverse it requires multiple changes that I was just not willing to do so far. :)
my thoughts on the #fediverse at the moment is that #ActivityPub needs something more akin to Sendmail, where the server holds the identity of the user, but like email we need another app to access / use it.
thus making accounts easier to have, and the apps like Mastodon and Pixelfed more presentation, rather than identity.
@jakeosx I'm already working towards this goal with my generic ActivityPub service called #FedBOX. You can see an example instance at https://federated.id (but there are no real stand-alone clients :D).
Today, I've "started" on a server-side frontend for servers like #FedBOX. By "started," I mean I set up a boilerplate between Deno and Fresh and now I've got to decide on the design (that's a pretty big part of a web frontend!).
I'm probably just going to use the federated.id server to test against for now, but when it's time to start writing stuff, I'm going to have to spin up my own server.
An #ActivityPub protocol extension where you can host your own identity server or use a public one and login to any ActivityPub service through that (thereby using any interface with the same Fedi account) would be kinda nice I guess.
Being thrown back onto a different platform (and the corresponding interface) just to comment is really bad in terms of UX. 😕 It kinda works for (Micro)blogs, Image Blogs and Video platforms. Forums probably too... but Link Aggregators like Kbin or Lemmy? Meh.
I want to convince myself to write an agnostic #ActivityPub server, and I have a killer name for it that both hits the topic and can take advantage of a new TLD...
The idea for this one is: it has a wide-ranging backend based on AP & the AP C2S API with a smaller server-specific API for what doesn't fit there (I think it'll be mostly admin stuff, like moderating instances). The frontend would be decoupled and the default frontend would also expose the Mastodon API because of course!
@blake if you can suffer not being the trailblazer, I wrote most of what you're describing in the form of #FedBOX the generic ActivityPub service. (No Mastodon API though)
one thing thatll stay really cool for a while is that I can submit stuff on #kbin, and people from masto will reply on it without even realising that they're talking to kbin
Oh man, I forgot the rush of endorphins that comes from fixing a really longstanding bug.
#FedBOX, the generic #ActivityPub service, had a heisenbug for about 6 months where integration tests for federated dispatch would randomly (and rarely when debugging) failed. I tried a couple of times to reproduce it, but it wasn't that big of a deal and it mostly went fine, so I didn't want to dedicate too much time to it.
1/2
One of the small things I managed to do while sick this week was to add support for <link rel=alternate type="application/activity+json"> for all the pages where this makes sense.
So now the instance and the individual users are directly discoverable on Mastodon instances by entering the URL in the search box. (Accepting the follows is not functional at the moment... oops)
One of the small things I managed to do while sick this week was to add support for <link rel=alternate type="application/activity+json"> for all the pages where this makes sense.
So now the instance and the individual users are directly discoverable on Mastodon instances by entering the URL in the search box. (Accepting the follows is not functional at the moment... oops)