moim.live 메인 화면에 뜨는 캐러셀에 뜨는 이벤트 배너도 우선순위를 조절할 수 있게 했다.

상업용 배너 > 그룹 이벤트 배너 (우선순위 내림차순 정렬) > 개인 이벤트 배너 (이건 그룹 이벤트가 진짜 없을때....)

커뮤니티 혹은 오피셜 그룹에서 게시한 이벤트는 최대한 우선순위를 땡기는 식으로 유연하게 대응하려고 한다.

#moim_live #fedidev

I've been thinking about adding federation health monitoring to #Fedify—not as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.

Does this sound useful to you? I'm curious whether people building on Fedify—or running federated servers in general—would actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.

#fedidev #ActivityPub

With ActivityPub / ActivityStreams...

To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.

That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.

I'll just call this common parent: 'Entity'.

...

It could have even been an opportunity to talk about how to handle unknown types.

#ActivityPub #ActivityStreams #FediDev #Fediverse

@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.

#ActivityPub #FediDev

I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8–9, Taipei)—think FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?

(Boosts appreciated!)

#ActivityPub #SocialWeb #fedidev #COSCUP

Właśnie zaimplementowałam w #Nicolium funkcjonalność usuwania Śledzika z wykorzystaniem kodu „5P13RD4L4J-5L3D21U” 🚀

https://codeberg.org/mkljczk/nicolium/commit/a8fc1717c443d091d5f90ea45b1e9af44dc45b0c

#FediDev #NicoliumDev

FEP website now displays the number of implementations for each implementable proposal:

https://fediverse.codeberg.page/fep/final/

These numbers are based on the information that authors provide in the "Implementations" section of a proposal.

By default, proposals are informational, so authors need to opt in by adding type: implementation to the metadata block.

#fep #fedidev

RE: https://mastodon.social/@fediversereport/116178002926045553

Laurens Hof is at it again highlighting the problems of our lack of an adequate ActivityPub API and the hurdles that are to come in it getting adoption.
#fedidev

#moim_live #fedidev

I'm building an open source ActivityPub service called "Moim" — 모임 in Korean, meaning gathering or meetup. It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes — but places carry meaning on their own, even in quiet, ordinary moments.

So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.

Right now, I'm focusing on three areas:

• CRM for Event Organizers A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
• A Federated RSVP Service I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse — and ideally, better. Being federated shouldn't mean settling for less.
• A Check-in Sharing System I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.

I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using. If I'm ready, I will officially announce to public.

#FediDev is there a generic Android intent for sharing to the Fediverse?

以前から、東アジアにもFediConのようなイベントがあればいいなと言い続けてきました。独自のカンファレンスはまだ難しそうですが、小さな一歩として考えていることがあります。

@COSCUP 2026（台北、8月8日〜9日）がコミュニティトラックの提案を受け付けています。FOSDEMのSocial Web devroomのような感じで、Social Webトラックを開けないかなと思っているところです。

まだ構想段階ですが、ActivityPubやフェディバース、ソーシャルウェブ全般に取り組んでいて、発表や共同オーガナイズに興味があるという方がいれば、ぜひ話しかけてください。

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #ActivityPub #fediverse #フェディバース #COSCUP #fedidev

東(동)아시아에도 FediCon 같은 行事(행사)가 있으면 좋겠다는 말을 여러 番(번) 해왔는데요. 獨立的(독립적)인 컨퍼런스는 아직 어렵더라도, 작은 첫걸음으로 생각해보고 있는 게 있습니다.

@COSCUP 2026(臺北(타이베이), 8月(월) 8日(일)–9日(일))이 커뮤니티 트랙 提案(제안)을 받고 있어요. FOSDEM의 Social Web devroom 같은 느낌으로, 거기서 Social Web 트랙을 열 수 있지 않을까 하고 構想(구상) 중입니다.

아직 確定(확정)된 건 아무것도 없지만, #ActivityPub, #聯合宇宙(연합우주), 或(혹)은 소셜 웹 全般(전반)을 다루고 있고 發表(발표)나 共同(공동) 오거나이징에 關心(관심)이 있으신 분이 있다면 이야기 걸어주세요.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #fediverse #연합우주 #페디버스 #COSCUP #fedidev

I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:

@COSCUP 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.

Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #COSCUP #fedidev

Today @kopperkopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even exciting—but never comfortable. That era where your business logic and your protocol plumbing were just… the same thing:

print "HTTP/1.1 200 OK"
print "Content-Type: text/html"
print
print "Hello, world!"

Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.

ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And wait—what's Linked Data Signatures, and do you need that too?

The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows it—every edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.

What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you just… build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.

#fedidev #fediverse

Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

#fedidev #fediverse #PortableObjects

RE: https://planet.moe/@oeee_cafe/115615511184864588

Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet.
#fedidev

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent a follow request—but the Accept never came back, even though they hadn't enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.

I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.

This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.

I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.

That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.

One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.

After all that, the mutual follow went through and my DM reply landed. Worth it.

#fedidev #fediverse #Hollo #HackersPub

came across a thread by @LiquidParasyte about things they are coming across that need work or are broken on @Bonfire
https://indieweb.studio/post/01KJ0T79KGJRWHYTKWJJF4254R
#fedidev #bonfire

3/

Interestingly, the Fediverse already has a decentralized equivalent to https://plc.directory .

On the Fediverse it is where a Fediverse ID:

＠joeblow＠example·com

Is resolved using WebFinger:

https;//example·com/.well-known/webfinger?resource=acct:joeblow＠example·com

Which points you to the activity page:

https;//example·com/users/joeblow

Which returns the activity actor JSON-LD.

(BTW, plc.directory also returns JSON-LD)

#ATmosphere #bluesky #bsky #did #didplc #FediDev #Fediverse

2/

Many have hoped that Bluesky decentralizes DID-PLC & https://plc.directory , or replace it with something decentralized.

And, I do think the Bluesky founders want to fix this — "plc" is short for "placeholder" after all.

But, it isn't decentralized yet.

Interestingly...

#ATmosphere #bluesky #bsky #did #didplc #FediDev #Fediverse

1/

One of the places where many are hoping Bluesky and the ATmosphere improves is — DID-PLC.

DID-PLC and the centralized server https://plc.directory are at the core of what identity on Bluesky and the ATmosphere is based on.

Unfortunately it is centralized — which is a problem if you are trying to build a decentralized social-networking platform.

...

#ATmosphere #bluesky #bsky #did #didplc #FediDev #Fediverse

RE: https://mastodon.social/@reiver/112133984854710390

"A guide to implement ActivityPub in a static site (or any website)" by @mapacheMaho 🦝🍻

https://maho.dev/2024/02/a-guide-to-implement-activitypub-in-a-static-site-or-any-website/

#ActivityPub #ActivityStreams #FediDev #FediDevs #Fediverse

My posts on Mastodon say that no one is permitted to quote-boosts my posts — yet I never made that choice.

(I'm actually OK with others quote-boosting my posts.)

I know enough to be aware this.
Most aren't.

A very large number of people have no idea that someone else made this choice for them.

I suspect the vast majority of them would have chosen the opposite.

I think Mastodon should have represented "user has not chosen" in the JSON-LD.

#ActivitiyPub #FediDev #FediDevs #Fediverse #fep044f

Hi #fediverse and #ActivityPub developers!

I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.

Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!

#fedidev #BonfireNetworks

"Fedify 2.0.0 está aqui!

Esta é a maior atualização da história do Fedify. Destaques:

**Arquitetura modular** – O pacote monolítico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulário personalizados.

**Painel de depuração em tempo real** – O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o tráfego de federação: traces, detalhes das atividades, verificação de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.

**Suporte a relay do ActivityPub** – Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatível com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).

**Entrega ordenada de mensagens** – A nova opção `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave são entregues garantidamente na ordem FIFO.

**Tratamento de falhas permanentes** – `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessíveis em vez de tentar reenviar indefinidamente.

Outras novidades incluem negociação de conteúdo no nível do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rápido de projetos, arquivos de configuração para a CLI, suporte nativo à CLI em Node.js/Bun e diversos fixes de bugs.

Esta versão conta com contribuições significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!

Trata-se de uma release major com breaking changes. Consulte o guia de migração antes de atualizar.

Notas completas da release: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverso #fedidev #TypeScript"

@fediverseFediverso @tecnologia @academicosAcadêmicos do Fediverso @internet (pode seguir para acompanhar os assuntos ou marcar para amplificar a postagem até no #lemmy tb)

@fedifyFedify: ActivityPub server framework https://hollo.social/@fedify/019c8521-92ef-7d5f-be4d-c50eae575742

Fedify 2.0.0をリリースしました！

Fedify史上最大のリリースです。主な変更点をご紹介します：

• モジュラーアーキテクチャ — これまでのモノリシックな@fedify/fedifyパッケージを、@fedify/vocab、@fedify/vocab-runtime、@fedify/vocab-tools、@fedify/webfingerなど、独立したパッケージに分割しました。バンドルサイズの削減、インポートの整理に加え、カスタム語彙型によるActivityPubの拡張も可能になりました。
• リアルタイムデバッグダッシュボード — 新しい@fedify/debuggerパッケージにより、/__debug__/パスにライブダッシュボードを表示できます。連合トラフィックのトレース、アクティビティの詳細、署名検証、ログまで一目で確認できます。既存のFederationオブジェクトをラップするだけで使えます。
• ActivityPubリレーサポート — @fedify/relayパッケージとfedify relayCLIコマンドで、リレーサーバーをすぐに立ち上げることができます。Mastodon方式とLitePub方式の両方に対応しています（FEP-ae0c）。
• 順序保証メッセージ配信 — 新しいorderingKeyオプションにより、「ゾンビ投稿」問題を解決しました。DeleteがCreateより先に到着してしまう問題がなくなります。同じキーを共有するアクティビティはFIFO順序が保証されます。
• 永続的な配信失敗の処理 — setOutboxPermanentFailureHandler()で、リモートのインボックスが404や410を返した際に対応できるようになりました。到達不能なフォロワーの整理などが可能です。

その他にも、ミドルウェアレベルでのコンテンツネゴシエーション、@fedify/lint、@fedify/create、CLI設定ファイル、ネイティブNode.js/Bun CLIサポート、多数のバグ修正などが含まれています。

今回のリリースには、韓国のOSSCA（オープンソースコントリビューションアカデミー）参加者の皆さんからの多大な貢献が含まれています。ご協力いただいた全ての方に感謝いたします！

破壊的変更を含むメジャーリリースです。アップグレード前にマイグレーションガイドを必ずご確認ください。

リリースノート全文: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0을 릴리스했습니다!

Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:

• 모듈형 아키텍처 — 기존의 단일 @fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.
• 실시간 디버그 대시보드 — 새로운 @fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.
• ActivityPub 릴레이 지원 — @fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).
• 순서 보장 메시지 전달 — 새로운 orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.
• 영구 전달 실패 처리 — setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.

이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.

이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!

브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.

전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0 is here!

This is the biggest release in Fedify's history. Here are the highlights:

• Modular architecture — The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
• Real-time debug dashboard — The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
• ActivityPub relay support — First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
• Ordered message delivery — The new orderingKey option solves the “zombie post” problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
• Permanent failure handling — setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.

Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.

This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!

This is a major release with breaking changes—please check the migration guide before upgrading.

Full release notes: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

In the old blogging software I created back in the 1990s, I had a handful of posts types

There was a type of rich-text oriented post that had a title. (Article)

And, there way another type of rich-text oriented post that did not have a title. (Note)

(There were also other types of posts, but they aren't relevant here)

These 2 types of posts were rendered / displayed differently

I.e., my 1990s software already had this distinction

#ActivityPub #ActivityStreams #FediDev #FediDevs #Fediverse

I've seen an ongoing debate between "Note" versus "Article" in ActivityPub / ActivityStreams.

When is something a "Note"‽
When is something an "Article"‽

Personally — I would probably have made the distinction this way.

An "Article" has a title.
A "Note" doesn't have a title.

(In ActivityPub / ActivityStreams, a 'title' seems to tend to get represented in the "name" field.)

#ActivityPub #ActivityStreams #FediDev #FediDevs #Fediverse

Today @mkljczknicole mikołajczyk introduced a proposal for MAEPs (Mastodon API Enhancement Proposals) which would be similar to the FEP process but for converging on API schema for servers that are not Mastodon but who are using the Mastodon client API
https://codeberg.org/fediverse-pl/maep/issues/1
#fedidev #fediverse #MAEPs

MastoAPI Enhancement Proposals? I'd like to hear some opinions about the idea.

https://maep.fediverse.pl/issues/1

#FediDev

Unfortunately for anyone reading this, I had an idea, although I'm not ready to talk publicly about it.

But I do have a question for #fedidev s out here: Is there a nice way to handle account fragmentation? So having 3 accounts for 3 platforms that need to write-interact with the activitypub stream?
Really new to all of this, sorry if this question is kinda noob-y

#Fedidev #ActivityPub

@strypey discussions about development are often tagged with #fedidev

Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?

Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.

If there's interest, I'm happy to write up the rest of this as an additional #FEP

@silverpill
@rimu
@evanEvan Prodromou
@trwnhinfinite love ⴳ
@julian
@ricferrerRicardo Ferrer Rivero🇪🇺

Your Home Feed is the inbox of an ActivityPub actor — in particular YOUR ActivityPub actor.

There could be an actor for each hash-tag, too.

You could even do Del.icio.us like things — and have actors for intersections of hash-tags, too.

These hash-tag actors' inboxes would need to be readable by anyone.

...

This could be a more ActivityPub like API alternative to Mastodon's "GET /API/v1/tags/{name}" API.

#ActivityPub #FediDev #FediDevs #Fediverse #HashTag #HashTags

FEP drafting: Am I using “side effects” here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.

#ActivityPub #FediDev #FEP

there is currently a #Piefed Hackathon going on if anyone is interested in partaking. There are groups working on spanish, german, french and japanese translations, and a bunch of other things.

https://tarte.nuage-libre.fr/c/fediverse/p/221411/hackathon-this-week-7-8-febuary #fediverse #fedidev #activitypub

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

2/

RE: https://mastodon.social/@reiver/115945290105913697

The resolving of a Fediverse ID to one or more cryptographic public-keys could happen via the activity-file for the user.

A JSON-LD namespace (separate from ActivityPub) could put the cryptographic public-keys into the activity-file.

But, I think we would need more information than what the 2 current methods for including cryptographic public-keys currently support.

#ActivityPub #Cryptography #FediDev #FediDevs #Fediverse #JSONLD

1/

RE: https://mastodon.social/@reiver/115945290105913697

Right now, Fediverse IDs resolve to HTTPS URLs.
For example, the Fediverse ID:

＠reiver＠mastodon.social

Resolves to HTTPS URL:

https;//mastodon·social/users/reiver

...

If we wanted cryptographic public-keys to serve as a basis of Identity on the Fediverse, then —

We would (similarly) also need a Fediverse ID to resolve to one or more cryptographic public-keys

...

#ActivityPub #Cryptography #FediDev #FediDevs #Fediverse #JSONLD

I dream of being able to store my online social presence, identity, and history just as — an (organized) set of static files.

A set that I control.

And, I can (if I want to) host myself. (I.e., I am the "source of truth" / "origin" for my files.)

RE: https://mastodon.social/@reiver/116018261922778583

#ActivityPub #FediDev #FediDevs #FediUX #Fediverse #FediverseUX

3/

If you cannot get (most) regular people to write JSON-LD, JSON, or even HTML —

But, you might be able to get them (regular people) to write something similar to Markdown and INI —

Then, are there ways you could (explicitly or implicitly) encode JSON-LD type information, such as ActivityPub, into a Markdown-like or INI-like file — in a way where they (regular people) would likely include it?

I suspect — probably yes.

#ActivityPub #FediDev #FediDevs #FediUX #Fediverse #FediverseUX

RE: https://mastodon.social/@by_caballero/115968453192473247

interesting writeup about federated package management by @andrewnezAndrew Nesbitt
#fedidev

@Bonfire: Modular Communication Tools on the Open Social Web
https://fosdem.org/2026/schedule/event/LSUYXG-bonfire_modular_communication_tools_on_the_open_social_web

#fedidev #ActivityPup

#Fedidev people at #FOSDEM 2026, where are you today?

So… the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!

#fedidev