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.
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.
In case someone wants possibly the longest thread on the fediverse for testing purposes, here you go: https://mastodon.social/@brownpau/112322747861701800
With the way I store replies in #Smithereen, this will soon exceed my limit of 256 levels ¯_(ツ)_/¯
I believe Flipboard will prove to be a counterweight to Threads and a prime location for news & pundits (as #Meta does not really desire the latter two on their platforms).
Flipboard curators have seen over 100,000 boosts, likes and replies from people across the fediverse since April 11. Given this positive signal from the community, today we're federating another 100 accounts representing more than 2,500 Magazines about everything from climate to culture. Read more here:
#Fedify, an #ActivityPub server framework, has released version 0.8.0! Here are the highlights of this version:
• fedify lookup: a command to look up any ActivityStreams objects (including actors); see also https://todon.eu/@hongminhee/112341925069749583
• fedify inbox: a command to spin up an ephemeral ActivityPub server so that you can debug and test the activities you send; see also https://todon.eu/@hongminhee/112354353470490915
• followers collection synchronization mechanism
• improved overall performance
• fixed several bugs
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,”
I have raised the alarm bell already several years ago. Explained how the (at that time mostly dormant) Working Group at the W3C that is responsible for #ActivityPub must be reinvigorated (that happened) and must became a loud defender of the #fediverse (that didn't happen) or else we risk losing our ecosystem to fragmentation and infighting.
And creators like @thelinuxEXP have mentioned multiple times that the lack of financial incentives to post their content on e.g. PeerTube vs. YouTube acts as a deterrent for many.
And the Fediverse community in general has already a strong sense of “reward-based” ethics - many already make LibrePay/Patreon donations to their instance admins and favourite content creators, so why not embed such ability in the protocol itself and bypass the middlemen?
Allowing micropayments in ActivityPub (per-post, one-off, recurrent etc.) would actually attract many creators who are currently stuck against their will on proprietary platforms, are at the mercy of YouTube’s mercurial monetization algorithms, don’t have much freedom in deciding how they want to get paid, and have to give back a non-negligible share of their revenue to the platform itself.
Imagine instead a world where micropayments are handled at protocol level itself, a piece of content or a profile that requires the user to make a payment would transparently respond with an HTTP 402, the money would move from the donor’s account to the contributor’s without any middlemen to shave off profits, no external algorithms are in charge of what can be monetized and how, and creators don’t even have to worry about posting the same content across multiple different platforms because ActivityPub would take care of the whole distribution problem. I can’t think of a better silver bullet to get content creators to do the jump.
The thing is that if we don’t implement this right on the protocol level because we oppose commercialization on ideological grounds, then Threads may implement it anyway on their version of ActivityPub (and then yes, it’d really be E-E-E), and content creators who do content creation as a job have one more reason to avoid the Fediverse.
I’ve got a bit more of a mixed feeling about ads instead. There’s sensitivity on the Fediverse about donations and micropayments, but almost everyone here hates the ad-based business model to the core. If the payments idea and implementation works right, then I don’t think we need to pollute our walls with such low-quality littering. I’m happy to leave that to Threads if they want to implement it, because I really don’t see much of added value in it and I don’t see why anybody out there would like that idea.
@Chocobozzz@thelinuxEXP@Techaltar@dansup@jwildeboer I would add that any implementation of a payment subsystem should probably be done at protocol level, so individual implementations of #ActivityPub don’t have to reinvent the wheel - doing #payments right is a hard problem, and it doesn’t make sense to fragment the efforts by solving the same problem multiple times on Mastodon/WriteFreely/PeerTube/Pixelfed etc.
The payments subsystem should be better integrated in the ActivityPub ecosystem compared to a “Donate here” link that redirects to a 3rd-party provider. This is probably the right chance of giving the HTTP 402 code the implementation it deserves.
I left the payments industry a few years ago so I’m not sure of what open solutions and protocols are in the market that could be already leveraged, but maybe something like OpenPayments could be a good starting point - there are many efforts on the open banking standards lately, with different degree of maturity, and IMHO a good implementation of payments over ActivityPub could be a great driver for adoption.
I’ve got the feeling that if we don’t do this right then Threads could scoop up this chance for an “embrace” to “extend” pivot.
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.