I like @Mastodon, however I am also flirting with the #XMPP could-have-been, @movim as a platform to discover. If only #Movim had proper #ActivityPub compatibility.
Somebody is making a coop version of bandcamp?
I am exited for the possibility of this! I am always looking for better ways of buying music directly from artists and small labels since bandcamp has been getting sold and traded about so much
I'm following this tutorial by @Gargron, does anybody know if this is still up to date? I can't get Mastodon to find my test-actor in search. The inbox exists and can be posted to, the actor verifyer tools tell me it that it should be valid. I can see in my logs, that the mastodon instance I am searching for is accessing my actor endpoint, but in search, it tells me nothing can be found
I actually started #Fedify because I was working on a single-user #ActivityPub implementation called #Hollo and felt like I needed some groundwork, and now that I'm somewhat done yak shaving, I'm back to working on Hollo, although I still jump back and forth between Hollo development and Fedify when I think of features I need for Fedify.
A little bird told me that when #Threads will be totally into #ActivityPub then #Mastodon will mysteriously lose the ability to block entire domains/servers... 🐦
@dansup there used to be a full-blown (non-federated) remake of Stackoverflow in a GH project. Firing it up would give nearly the same UI and a whole bunch of the gamification features.
I was only mildly interested at the time, and did not star or anything. Later on, seeing "federated SO" thread for the N-th time I tried to find it again on multiple occasions. No luck, unfortunately.
Such project would be a great basis to add #ActivityPub to.
So #Bluesky is implementing an (unspecified) new protocol for direct messages. Because AtProto is really not suitable for anything that isn't 100% public.
I wonder whether they can do this now that Jack is off the board. But maintaining two separate protocols in the same app? Who knows, maybe #ActivityPub is next?
Looking into this Summer of Protocols thing that @evan and @tomcoates got accepted for to work on adding encryption to #ActivityPub, and realized its a grant from the Ethereum Foundation. I am not opposed to crypto slush money flowing into more useful projects like the #fediverse but thought it was interesting that I hadn't seen anyone mention this fact yet.
#activitypub The Podcast Index ActivityPub bridge now properly handles Mastodon "authorized fetch". If you had trouble following a podcast from an authorized fetch enabled instance, please cancel that follow and try again.
This may also resolve other sporadic follow issues from Sharkey/Misskey instances. Testing from people on those platforms would be welcome.
Trying to work out the best way to distribute an update to a group of ActivityPub users directly (so, like it's being sent to their inbox — like they're followers) but separate from a follower relationship. Then those updates could be displayed for those users in a separate timeline from the main home timeline.
Can you have multiple inboxes? The spec says something about allowing extensions — could you augment it to add your own extra inbox that anyone using your extended protocol would be able to access?
Best way I can think of right now is to deliver the updates to the recipients' inboxes, then have the recipients determine whether to show in the regular timeline or the extra one based on whether the sender is followed. But that would clutter the default timeline for other #ActivityPub clients.
The whole idea of BlueSky supporting nomadic identities but the rest of the ActivityPub (plus other stuff) Fediverse being unable to do so is such an oversold idea.
A new service using ActivityPub behind the scenes (and not the AT Protocol) can absolutely support nomadic identities, even if the service doesn't treat a whole website as the actor.
It will still use did:plc, same as AT Protocol (BlueSky), but once done so, an application that understands how to work with did:plc can dereference an actor based on the DID.
That said, an existing service will simply not be compatible with this idea, without changing how it operates.
I'm glad to announce the release of version 2.52 of #snac, the simple, minimalistic #ActivityPub instance server written in C. It includes the following changes:
Posts that were liked or boosted can now be unliked and unboosted.
Outgoing message timeouts are no longer hardcoded and can be configured (see snac(8) for more information).
Fixed a bug that caused some incorrect unfollows under special conditions (with shared inboxes enabled and users from the same instance that follow each other, the internal message distributor was confused).
Mastodon API: Added support for lists.
Added a header to avoid over-zealous caching in some browsers (contributed by louis77).
Added support for running and federating inside hidden networks like Tor, I2P or Loki (contributed by iwojima).
Fixed an error processing polls coming from Pleroma instances.
tootik is a federated nanoblogging service for the small internet.
tootik allows people to participate in the fediverse using their Gemini, Gopher or Finger client of choice and makes the fediverse lighter, more private and more accessible. tootik's interface strips content to bare essentials (like text and links), puts the users in control of the content they see and tries to "slow down" the fediverse to make it more compatible with the slower pace of the small internet.
It's a single executable that handles both the federation (using ActivityPub) and the frontend (using Gemini) aspects, while sqlite takes care of persistency. It should be lightweight and efficient enough to host a small community even on a cheap server, and hopefully, be easy to hack on.
tootik implements only a small subset of ActivityPub, and probably doesn't really conform to the spec.
Every time a truly open protocol emerges, the vultures that shout "monetisation" will show up and demand that artificial scarcity must be created or else they will not come. But adding artificial scarcity to an open system makes it non-open. 1/7
@jwildeboer#monetisation should not be part of a communication system. It can be part of the system around it, but for that #ActivityPub does not have to change.
Sono pienamente d'accordo con la libertà del #fediverso infatti appena ritirerò su @ilmondopositivo il plugin #activitypub avrà la priorità assoluta. Dopo, certo, possiamo non essere d'accordo con camere chiuse e polarizzazioni ma non lasceremo passare a commentarci omofobi e odiatori. Quelli se ne tornino da dove sono venuti 🫡🖕🚽 perché libertà di pensiero sì, ma odiare non fa parte della libertà. https://mastodon.uno/@socialnetwork/112398307915936196
But if #BridgyFed becomes more user-friendly, that will be a big step towards interoperability. And we can finally put this silly competition between #ActivityPub and #ATProtocol to rest.
Facebook/Meta starts talking about the "Extend" phase of Embrace, Extend, Extinguish as predicted:
"“You could imagine an extension to the protocol eventually — of saying like, ‘I want to support micropayments,’ or … like, ‘hey, feel free to show me ads, if that supports you.’ Kind of like a way for you to self-label or self-opt-in. That would be great,”
GNU @Taler is free software, and @NGI_Taler has open calls to let you implement the payment system for your free software. It would totally make sense to apply at protocol level to solve it for #ActivityPub federation.
From what I understand, everybody within the @EU_Commission was very happy and supportive of the #EUVoice experiment by @EDPS. Everybody within @EC_NGI is absolutely delighted with the work done by @NGIZero, yet, when EDPS asked what branch of the European Union would take charge of the #ActivityPub presence of the Union, everybody turned they heads away.
Yet, the #EU keeps spending tons of public money on X or Meta. This is #shameful.