Does anyone here have experience with federated Forgejo (v13.0.4)? I set it to enabled in the .ini file and restarted, but what will happen as a result? Can people who use other instances now star my repos, or do I need to configure something else?
federation
“I feel like we're rebooting to the last version of the Internet that I felt uncomplicated joy about.”
@Casey, @kevin and @pj on why they set up their Forkiverse fediverse server.
https://www.searchengine.show/the-fediverse-experiment/
#Fediverse #Federation #ActivityPub #Forkiverse #OpenSocial #OpenSocialWeb #Internet #Technology #Tech
@newyorktimes's veteran tech reporter @Markoff interviewed some of #TeamFediverse including @Gargron, @reckless1280 and our CEO @mike for a feature on the rise of decentralized social media. “It goes back to the original principles where the internet started out as decentralized,” Eugen Rochko told Markoff. Here's the full story [may be paywalled].
We're so excited to develop these conversations further at SXSW this weekend — check out the itinerary and sign up to join us at #FediverseHouse at the second link.
#Fediverse #ActivityPub #Federation #OpenSocialWeb #SXSW #JohnMarkoff #EugenRochko #MikeMcCue #SXSW2025
Edited 353d ago
Quote Repost is coming to Mastodon!
I'm glad they're taking time to think this through.
#mastodon #federation #fediverse
https://blog.joinmastodon.org/2025/02/bringing-quote-posts-to-mastodon/
I've been wrestling with implementing #multilingual content support in Hackers' Pub, our #ActivityPub-powered platform for software engineers.
While ActivityPub theoretically supports multilingual content through the contentMap property, the reality is that most server implementations (Mastodon, Misskey, etc.) don't properly handle this content as of April 2025. This creates a significant challenge for us.
We want our users to share their knowledge in multiple languages, but we need to ensure compatibility with existing ActivityPub servers. I'm considering several approaches:
Creating separate posts for each language with clear language indicators, linking them through inReplyTo relationships (so translations appear as replies to the original post)
Using the primary language in content while storing translations in contentMap
Adding "View in other languages" links at the bottom of each post
Implementing inline language dividers that degrade gracefully on non-supporting servers, for example:
<div lang="en"> <h3>English</h3> <p>This is the English content…</p></div><hr><div lang="ko"> <h3>한국어</h3> <p>한국어 내용입니다…</p></div>
I'm leaning toward a hybrid approach—showing content in the user's preferred language when possible while providing easy access to other language versions.
Has anyone tackled this problem effectively? I'd love to hear about your experiences or ideas for making multilingual content work well in the fediverse, especially when dealing with server implementations that don't fully support ActivityPub's multilingual features.
Today, we're beginning to federate publisher accounts in Italy, France and Spain, and expanding in Brazil and Germany.
You can now follow even more of your favorite news, lifestyle, tech and sports sources from Flipboard on the open social web. Read more about it here. See the spreadsheet at the second link for the full list of federated profiles.
https://docs.google.com/spreadsheets/u/1/d/1iUFTo6rPvhqzCReLaM1c6-xUKRuBVqlZVStZl9Al-EU/edit
#Federation #Flipboard #Fediverse #OpenSocial #OpenSocialWeb #Germany #Deutschland #France #Spain #España #Italy #Italie #Brazil #Brasil #News #Media #Journalism #Publishers
📢 Wir haben Neuigkeiten! Flipboard erweitert die Föderation in Deutschland: 21 neue Publisher sind jetzt im Fediverse.
Diesen Publishern kannst du ab sofort direkt folgen:
AZMuenchen, @AZMuenchen
BASICthinking, @BASICthinking
Business Punk, @BusinessPunk
BUNTE, @BUNTE_DE
CURVED, @curved
DER SPIEGEL, @DerSpiegel
DerStandard, @DERSTANDARD
Filmstarts, @Filmstarts
FitForFun, @FitForFun
Futurezone, @Futurezone_de
GIGA, @Gigade
Gruenderszene, @Gruenderszene
Harvard Business Manager, @harvardbusiness
Kino.de, @kinode
Men’s Health, @MensHealth_de
Metal Hammer, @metalhammer_de
n-tv, @ntv2019
Photografix, @Photografix
Premium Quarterly, @PremiumQuarter
SZ, @SZ_de
Ze.tt, @Zett
Mehr dazu in unserem Blog: https://flip.it/cxfY1U
#Fediverse #Flipboard #Publisher #ActivityPub #Federation #Föderation #SocialMedia #Nachrichten #Politik #Unterhaltung #Journalismus #Digital #Tech #Wissenschaft #Wirtschaft #Klima #Musik
They may share a suffix (and a protocol), but Blacksky isn’t hitching its wagon to the Bluesky app or team. Founder and CEO @rudyfraser.com is creating a new, fiercely independent playbook for communities — one made possible because of the flexibility of the open web. We're excited for you to hear the latest episode of @mike's Dot Social podcast:
https://about.flipboard.com/fediverse/blacksky-rudy-fraser/
#DotSocial #Podcast #SocialMedia #SocialNetwork #Federation #OpenSocial #OpenSocialWeb #Blacksky #BlackMastodon @blackmastodon #RudyFraser #Technology #Tech #Bluesky
Edited 278d ago
Maybe rather than talking about federating everything on the web, we need to talk about federating what, and how.
In an interview with Simon Vansintjan from Mirlo, he talks about anyone with an account on their platform can create a music blog. It would be great to be able to subscribe to one of those blogs via ActivityPub, and get a notification in nu fediverse account whenever they publish new post.
(1/?)
Edited 252d ago
Ghost’s @johnonolan and WordPress’s @pfefferle want to help blogs and long content thrive on the open social web. Meet “the longformers,” who chatted to @mike for the latest edition of Dot Social.
https://about.flipboard.com/fediverse/john-onolan-and-matthias-pfefferle/
#DotSocial #Ghost #WordPress #Fediverse #FederatedMedia #ActivityPub #Federation
Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation
Curious what other people think about this idea. What if federation security was re-worked to use target-assigned bearer tokens to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).
A basic implementation could look like this:
1. When instance A (a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's https://b.example.com/activity-pub/register-instance). This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.
2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's https://a.example.com/activity-pub/verify-registration). This request must include the target domain name and verification token provided in step 2.
3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!
4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!
5. Instance A completes the original request with the Authorization header set to Bearer {federation_key}.
6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.
7. If the key does not exist or A has been defederated, then a 403 Forbidden error is returned.
8. If the key is expired or revoked, then 401 Unauthorized error is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!
9. If the key is approved, then a 200 OK response or 202 Accepted response is returned, and A can consider the request as successful.
Advantages versus HTTP Signatures:
- No cryptography requirements.
- Simple logic, no edge cases around HTTP query parameters or header order.
- Equally effective for all request types.
- Keys can be easily revoked or rotated.
- Supports authorized fetch and defederation use cases "by default".
Disadvantages versus HTTP Signatures:
- Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)
- Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.)
- Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)
So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here!
#ActivityPub #AP #Federation
Edited 216d ago