洪 民憙 (Hong Minhee)

Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.

I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.

I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!

#introduction

はじめまして！ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙（ホン・ミンヒ）と申します。バイセクシュアル（bisexual）・ノンバイナリー（non-binary）で、自由・オープンソースソフトウェア（F/OSS）とフェディバース（fediverse）の熱烈な支持者です。

STF（@sovtechfund）の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語（いわゆるCJK）とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体（漢字ハングル混じり文）の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください！

#自己紹介

安寧(안녕)하세요! 저는 서울에 살고 있는 30代(대) 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript用(용) ActivityPub 서버 프레임워크 @fedify 開發(개발)에 專業(전업)으로 任(임)하고 있습니다. 그 外(외)에도 싱글 유저用(용) ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript用(용) 로깅 라이브러리 LogTape 等(등)의 製作者(제작자)이기도 합니다.

東(동)아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 主(주)로 英語(영어)로 포스팅하지만, 때때로 日本語(일본어)나 國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) 中(중) 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

#툿친소 #연친소 #별친소 #자기소개

今週末開催される、 #oscnagoya では #FediLUG ブースにて、
・有志8人による執筆のThinking Penguin Magazine Vol.0（500円）
・和条門さん（ @naoki_wjm@k.my-sky.blue ）による『さばかんライフ！』（1000円）
・ホンさん（ @hongminhee@hollo.social ）による『自分だけのフェディバースのマイクロブログを作ろう！』（500円）
も頒布いたします！
そのほかにもステッカーや各種チラシも扱っておりますので、ぜひ足をお運びください！！

Fedify本届いた〜

I've been working on adding Cloudflare Workers compatibility to @fedify for a few days now, and I'm feeling a little tired. Cloud Workers seems to have bet on @vite support for local development environment, but the problem is that Fedify can't use Vite due to their bug. (This bug is said to be fixed in Vite 7.) So I feel like I'm solving the problems that Cloudflare employees should solve themselves.

@reiver Maybe @liaizon is thinking about this:

https://hollo.social/@hongminhee/0196d22a-6aed-75b6-a109-c2513b40b5f8

Zed 에디터의 비공식 윈도우즈 빌드를 발견했다. 윈도우즈에서 맛보고 싶지만 직접 빌드할 여건이 안 된다면 이걸 써보면 될듯? (일단 내 컴퓨터에서도 돌아간다.)

https://github.com/deevus/zed-windows-builds

I wish Cloudflare Workers supported the Temporal API...

This article is a follow-up to an older post of mine, Towards a Greater Federated Architecture, and also a response from the wonderfully-thought out piece by Ben Werdmuller, If I Started Fresh. The goal here is to take the lessons learned from a variety of systems to propose the Fediverse platform I have always wanted to build: Postmodern.

No code has been written as of yet, but I am learning to program, from the bottom up, backend to frontend. I have some background in game design, Web development, and API clients, but I'm working on the more elusive foundational stuff. This is the only way I can possibly develop the confidence needed to build this thing.

The Fediverse, Social Web, Peopleverse, whatever you want to call it, has evolved considerably since it originally started back in 2008. During my entire time on the network, I've longed to design a platform of my own. I've learned a lot of lessons from amazing projects along the way: Hubzilla, Bonfire, Emissary, and ActivityPods have all done some really interesting things beyond what Mastodon offers to the network. I also think there's some really valuable ideas in both Nostr and Bluesky that are worth closer examination.

Before I dive into my technical brain-droppings of the past decade, let's establish a few core concepts.

Guiding Principles

1. It needs to be fun

On the surface, this might sound superfluous. What does it mean for a platform to be fun? This boils down to a few key areas that Fediverse platforms struggle with:

• Ease of use - Good UX design is hard to execute well. As time goes on, I'm convinced that people want to use something without having to think too hard about conventions or side effects. They shouldn't have to dig under countless menus to find where the decentralization is.
• Discovery - For the time being, the act of finding new, cool things to interact with or peruse is pretty bad. There's some promising work happening with Fediverse Discovery Providers. Regardless, discovery needs to also extend beyond simply finding stuff, and include a laser focus on finding people. Onboarding still kind of sucks, and there's a number of issues with trying to find your friends and connect with them.
• Resiliency - One of the shakiest aspects of the Fediverse involves just how fragile instances can be. If an instance permanently goes down, and you didn't already have some alias set up to migrate your followers, you're dead in the water. Having to rebuild your social graph from scratch is the opposite of fun.
• Control - This can mean a lot of different things: control over your timeline, control over how your space on the web looks, control over your connections, control over your data. A big missed opportunity in the space is that we'll say things like "you own your own data", but it's not exactly true. Your data mostly exists as a series of tables in a database, which can be serialized into a JSON export that you mostly can't use with anything.

It might seem like this is a catch-all, where you can throw any old thing into the guiding principle. Maybe it is. What I know is this: if the experience is bad for users, if they're getting harassed and seeing drama every day, if they don't really have much control over the platform, if they can't find their friends or cool things that interest them, then your platform is the opposite of fun.

2. Users should have maximum agency

Building on top of Principle #1, individual users should have total agency of how their experience is shaped online. This can be categorized in four ways:

1. Visual / Conventional - the user decides what interfaces, themes, apps, and clients they will leverage to access the network. Custom designs and behaviors empower users to make their online space truly their own.
2. Data Sovereignty - the user has strict controls over their data: what apps and services can use it, the extent to which different pieces are exposed to the Web, and the ability to seamlessly port the sum of that data from one place to another.
3. Filtering and Connectivity - users should always be given the opportunity to decide what they see on their feeds, and what other people can see from them. This could take the form of filtering out keywords, blocking users and domains, leveraging a third-party labeling service, or being able to connect to individual accounts that may otherwise be banned instance-wide for everyone else.

Of course, this isn't to say that admins and moderators don't have a suitable place in community-building and curation. It's just that solely relying on them tends to result in communities where users have minimal input on policy, and admins have absolute authority. To me, this is a major barrier towards world-wide adoption of the Social Web, which is a goal for some of us in this massive, sprawling movement.

3. The platform must move the Fediverse forward

There's some absolutely amazing developments happening in the space. Most notably, the Fediverse Enhancement Proposals project has helped many different platforms standardize on undocumented behavior. It's the closest thing we have right now for improving ActivityPub implementations, in lieu of a formal update to the protocol spec.

FEPs are the reason why groups mostly just work across a variety of systems now, and related efforts such as the Threadiverse Working Group allows NodeBB, Discourse, Lemmy, PieFed, and Mbin to federate together with minimal issues. It's not perfect, but the project is bearing a lot of fruit.

The problem is that some of the biggest projects in the space, such as Mastodon, have historically been pretty indifferent to these efforts. Often, they choose to forgo established agreed-upon FEPs to do their own thing, forcing everyone else to bend over backwards and support their unique way of doing things. At the end of the day, FEPs still aren't advancements in the ActivityPub protocol itself.

We need more Fediverse platforms to champion these collaborative efforts, both to help influence further development of the protocol as well as putting pressure on larger projects to work with the community.

4.) The experience must be unique

This might come across as wildly conceited, but I don't want to build yet another clone of a service that already exists. I mean no disrespect towards the people doing that, but I think we've barely managed to scratch the surface of what can be built. There's a certain appeal in imitating existing familiar designs and paradigms, and iterating on them to be better.

What I want to do is develop new concepts that aren't quite like anything else. Sure, there may be a passing resemblance to half a dozen different things, but I want to develop something bold. I'm tired of describing the Fediverse as "the alternative" and want so badly to instead describe it as "the future", but we have to take much bigger risks to get there.

Implementation Details

Here are some of the pipe-dream ideas I've been refining over the years. There are probably a lot of aspects that still need key considerations, some of which is still above my ability to program! I'm currently going to school for Computer Science, and practicing to make my coding skills more capable of tackling these big ideas.

Composable Interfaces

This is probably the biggest idea behind Postmodern, the platform I hope to one day abuild. What are Composable Interfaces? To keep it simple: composable interfaces are a way to construct a custom frontend with whatever data is available.

Composable interfaces are not necessarily new; prior art exists in the following Fediverse projects:

• Hubzilla - You can write pages, a custom theme, and widgets using an elaborate template system. You have to write it yourself by hand, there's not really a way to preview these changes, and some of the more high-level customization has to be done by making calls to pieces of code that aren't super well-documented.
• Bonfire - Customization is largely accomplished through modules, which can be bundled together into a sort of unique software distribution. So, you can choose to add a group forum module, a wiki module, and a video module, and Bonfire will snap those pieces together for you. Super interesting, kind of complicated, still yet to be battle-tested for communities.
• Emissary - Really wild template system built on HTMX and HyperScript. Emissary is really different from other projects because it allows developers to dictate data schemas and actions from within the view template. A lot of contemporary developers might balk at this, because it kind of violates the MVC design pattern. However, Emissary is crazy flexible, and makes it possible for a developer to add support for custom Activity types and actions with a single template.
• Dokieli - a full-blown decentralized client-side editing tool. It implements ActivityPub, Linked Data, and a swath of other technologies related to Solid. It's extremely powerful, but the interface looks like it has a significant learning curve. It's hard even for me, a Fediverse nerd with 15 years of experience, to fully grok.

Looking at these concepts, I think Emissary and Dokieli come the closest to what I want to build. The ability to build a custom UI with unique capabilities just by dictating what the template is doing is awfully compelling.

My personal head-cannon differs in one specific way: take Dokieli, and marry its capabilities with that of Emissary. Focus on the page-building, widget-building, stream-building elements, and give people the power to delve into a vast pool of social data that they can edit client-side without having to touch any template code themselves.

Instead of taking inspiration from page-building tools like Gutenberg, Elementor, or Wix, my thoughts are to instead take inspiration from layer-based image editors. Each layer in the builder/inspector thing is a component, which can be altered, rearranged, and adjusted in a number of different ways. You can mix and match existing components, or compose your own from scratch by reaching into the pool of data that your account is aware of. It's not unlike the WordPress approach to Blocks in 2025...but, hopefully this approach can be more intuitive.

For this to be viable, a lot of work would need to be done to overcome any potential learning curve. The tools need to be accessible, with the page layout exactly matching what the user sees on the screen.The experience could really suck if it's not implemented carefully. After all, we have to follow the first guiding principle: it has to be fun. Fighting with an editing tool is not that.

To accomplish this, the most straightforward approach would be to create a core set of widgets with data types and settings, bundled together for different experiences. I'm calling these bundles-of-things complications, which can be thought of as the snapping together of atomic units to make something greater. An experience that has a lot of complications put together would pretty much work as its own frontend made of stylized, curated pieces.

If this sounds way, way complicated: yeah, I know. For a social client frontend, this idea pushes a lot of boundaries. I have some ideas about how to get there (maybe use GraphQL for the builder?), but a lot of it is going to probably diverge from the standard Web application stack. I have a lot of homework to do.

Next-Gen Permissions System

I've written about this a bit before in my last article about moving the Fediverse forward, but we need to get our act together about permissions systems. Mastodon's offering is woefully lacking when it comes to granularity.

ActivityPub has these nifty things called Collections, which is really just a representation of a collection of objects. You can pretty much put any object in there, so in a roundabout way, you can create a scoped list of people you're connected with. Theoretically, you could use collections of people as privacy scopes, dictating who can see certain things, or certain versions of things.

Projects such as Bonfire have taken the logical next step, where it's possible to establish boundaries and barriers for different collections of people, under a variety of conditions. This can apply to everything from individual posts to group communities to whatever else you can come up with.

I think it's absolutely important that we build a system that not only accounts for message delivery and access, but capabilities as well. You the user should be the one that dictates whether people can see a post, boost it, reply to it, whatever. In a decentralized system, this is kind of hard to figure out, but not impossible.

I still hold the belief that Object Capabilities might be our best bet, and Christine Lemmer-Webber published a paper a few months ago detailing what oCap-enabled ActivityPub would look like.m

Data as Documents

Some people will disagree with me here, but I think a document database architecture might be the way to go for this whole thing. A traditional relational database might be too limiting for this kind of insane flexibility, especially when you consider how different platforms try to account for the complex data structures necessary for ActivityPub.

Pleroma, for example, historically used the jsonb data type in PostgreSQL to hold reams and reams of nested JSON data. At a small scale, it's not so bad, but ActivityPub data can grow exponentially when you're interacting with lots of people and content.

For some time now, I've been thinking a lot about Sir Tim Berners-Lee's Solid Project. When first approaching Solid, it seems super abstract and complicated. You get all these people talking about RDF, TripleStores, Quads, WebID, and a lot of other stuff. As someone that has a pretty firm grasp on Fediverse systems, Solid initially caused a vein to bulge in my temple. I went on to explain the semantics here.

TL;DR: Solid is kind of a specification for data, data storage, and access. It allows users to store their data in pods, and that data is represented as different kinds of documents and metadata. There is no relational database. Instead, the data in your Solid pod is used as a database itself. If you wanted to migrate all of the posts you've ever made, Solid makes it super easy to pick all that stuff up and move it somewhere else.

ActivityPods manages to marry the two concepts, and does the heavy lifting to translate these documents and data into something ActivityPub implementations can understand, and vice versa. The real magic here is that ActivityPods makes the act of building ActivityPub apps relatively seamless and straightforward. Developers don't have to think about both ActivityPub and Solid. They just need to write an ActivityPub app.

I still have some outstanding questions about whether ActivityPods can effectively scale up. The Solid community in general is pretty small, and ActivityPods is an even smaller subset of either Solid or ActivityPub communities. A large-scale community instance with over 100,000 users (who all individually have their own pods) doesn't feel that feasible to me.

Still, I respect everything these guys are doing, and I think about building on top of ActivityPods pretty often.

Relay-Based Supportive Infra

Fediverse instances suffer somewhat from a fragile network. In fact, I would go as far as stating that tethering user accounts to Fediverse instances is an antipattern. We've mistakenly followed this trend for a long time, and put the sum of a user's entire social graph into one server. If that server goes down for good, you're toast.

Nostr doesn't have this problem, because it doesn't have instances. Instead, user accounts are free-floating, peer-to-peer identities that dispatch posts to individual relays. Instead of individual instances where everybody logs on to post, everything is done through clients. Your identity is basically a public key, tied to a profile and some posts.

What I'm advocating for isn't necessarily the prioritization of one method over the other, but a hybrid approach that includes the best of both. What if Fediverse identities could be free-floating, separate things from instances, that persist even when an instance goes down?

Suppose that the Move activity in ActivityPub was just a method for detaching the identity from one instance, and attaching to another? Or, taking the approach that Hubzilla takes, suppose that you could mirror your identity to multiple instances by attaching your identity to multiple servers? You post in one place, it shows up somewhere else, too.

Another way that relays could be useful is in attacking the notorious Discovery Problem so prevalent in the Fediverse. As Nostr has continued to evolve, different relays have emerged that specialize in specific things:

• Caching
• Hosting Media
• Search
• Premium Long-Term Storage

Theoretically, it could also be possible for relays to take on the role of Fediverse Discovery Providers. These things could not only act as an index of content and people, but conduits that pull in news, book reviews, events, and maybe even a contact directory. Maybe your instance could just subscribe to relays, rather than trying to broker message dispatching and pulling in new content itself.

A Single-Identity Ecosystem

Finally, we get to what I consider to be the Achilles heel of today's Fediverse. As highlighted in previous sections, I think we do a terrible job of handling identity. In fact, we don't really do any job at all.

Part of the problem here is that every Fediverse server in the network is a full-blown platform, rather than a client. The decision of the Mastodon project was to forgo the Client-To-Server part of the ActivityPub spec, instead opting for a bespoke API of its own. Mastodon's API grew so popular that many other Fediverse platforms adopted it, just to have access to a vast amount of compatible apps.

The primary side effect of every Fediverse server being a platform instead of a client is that every platform needs its own account to be used. This quickly leads to a nightmare scenario where it's possible to have 15 different accounts floating around that don't actually connect to each other in any meaningful way.

Granted, the Client-To-Server API has its fair share of complaints. It's under-documented, clients are expected to handle all logic on the client side, and seemingly nobody uses it anyway. However...it still exists, can be improved upon, and could be used in conjunction with ActivityPods.

I'm greatly interested in the prospect of building ActivityPods apps that work with Postmodern, where you're really just viewing different crafted experiences in specific clients.

In Conclusion

Congratulations on getting to the end of my big, weird rant about how I'd do things. Some of these ideas remain unproven, and may not actually be the solutions I end up going with. Still, much of this exists as the byproduct of lessons learned from observing different Fediverse platforms evolve over time. I hope to start by building small prototypes to test out various ideas.

Some of this (all of it?) might be super convoluted and complicated. The biggest thing I want to focus on, however, is the experience of building composable interfaces. I think this idea really has legs, and could potentially be a radically different approach to building for the Social Web.

If you have any insights, ideas, suggestions, or critiques, please feel free to reach out! This article was, believe it or not, something of a shortlist. There's a lot of things I didn't discuss (Bluesky-styled labelers, custom feeds, etc) that still belong in this vision somewhere. For now, these are simply the topics most resonant to me, that I wanted to pay special attention to.

이준석은 이번 한번에 그친 실수가 아니다. 이준석은 끊임없이 차별과 혐오에 기생하여 혐오세력의 인기에 영합하고자 폭력적이고, 반인권적이며, 공동체를 훼손하는 말들을 이어온 인물이다. 이준석이 원하는 것은 혐오발언을 선동하여 정치적 논란으로 확대재생산되어 만들어낼 혐오세력의 동조와 그를 통한 권력획책일 뿐이다. 이에 언론이 다뤄야할 것은 대통령 선거 토론회라는 생방송중에 정치적 도구로서 여성폭력을 전시한 이준석의 행태가 미칠 사회적 악영향이다.

[기자회견] TV 대선후보 정책토론을 성폭력 재생산장으...

이준석은 자신의 발언이 미칠 사회적 악영향에 대해 발언이후에 털끝만큼도 인식하지 못하고 있다는게 확인되었다. 끊임없이 여성혐오를 정치 공론장으로 끌어오며 우리 사회 민주주의를 훼손하는 이준석은 대통령후보가 될수 없다. 시민의 존엄을 침해하는 그가 국민의 대표일수도 없다. 그는 더이상 국민의 앞에 나설자격이 없다. 이준석은 당장 대통령후보직을 사퇴하라.

@root 까만색이라고도 해요. 그런데 글로 쓸 때는 검은색이라고 더 많이 써요.

Random PR of the day https://github.com/pbzweihander/fediday.org/pull/16

We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️

Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.

The proposal includes hierarchical labeling with categories like:

• type/ for bug, feature, documentation
• component/ for different parts of Fedify
• activitypub/ for interop issues with Mastodon, Misskey, etc.

We'd love your thoughts! What labels would be most helpful for contributors and maintainers?

Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.

#fedidev

연합우주의 날 프로젝트 홍보 https://fediday.org

Fedify 멘티 신청하고 왔습니당

When installing the patched versions of Misskey (Pull Request available) and Sharkey (with changes already applied) on a Fedora 42 environment, you may encounter the following errors:

error: ‘uint8_t’ was not declared in this scope
error: ‘state’ was not declared in this scope

These issues seem to stem from the version of GCC being used (Reference). Below, I will outline how to resolve these problems on Fedora 42.

Step 1: Install Dependencies

First, as indicated in the wiki, install the necessary dependencies:

sudo dnf install cairo-devel libjpeg-turbo-devel pango-devel giflib-devel pixman-devel

Step 2: Compile GCC/G++

Using the default GCC bundled with Fedora may lead to failed installations when running pnpm install (as of May 27, 2025). To avoid this issue, we need to compile and use a other version of GCC/G++.

Start by downloading the GCC source code using wget, then extract it and navigate to the source directory:

wget https://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-13.3.0/gcc-13.3.0.tar.gz
tar xzf gcc-13.3.0.tar.gz
cd gcc-13.3.0
mkdir build
cd build

Next, install the dependencies required for building GCC/G++:

sudo dnf group install development-tools
sudo dnf install mpfr-devel gmp-devel libmpc-devel zlib-devel glibc-devel.i686 glibc-devel isl-devel libgphobos-static

Now, configure the build (Flags should be changed as needed.):

../configure --disable-bootstrap --prefix=/usr --program-suffix=-13.3 --mandir=/usr/share/man --enable-languages=c,c++

After configuration, compile GCC with the following command:

make

To utilize multiple cores for a faster build, use the -j flag:

make -j6

Once the compilation is complete, install the new GCC version:

sudo make install

You can verify the installation of the compiled GCC using:

gcc-13.3 -v

Step 3: Modify Installation Command for Misskey/Sharkey

Finally, to successfully install Sharkey and Misskey, modify the installation command as follows:

CXX=/usr/sbin/g++-13.3 CC=/usr/sbin/gcc-13.3 pnpm install --frozen-lockfile

With these adjustments, you should be able to install Misskey and Sharkey without any issues. Enjoy Fediverse!

*I have used LLM to some extent to modify the text to make it more natural. I checked to some extent before post, but please let us know if there are any unnatural parts.

References

• Howto Build GCC 13.3 on Fedora 41/40 using GCC 14

OSS 컨트리뷰톤 지원했다...
하나는 이건 무조건 해야한다 싶은 거랑
하나는 2지망 지원하라길래 명목상으로 지원한거

(둘 다 메인테이너가 이 계정을 팔로하고 있다)

오늘 點心(점심)은 맑은 도미 鹽(시오)拉麵(라멘).

2025 오픈소스 컨트리뷰션 아카데미 참여형 멘티를 오늘부터 6월 22일까지 모집한다고 합니다. 저도 Fedify 프로젝트의 멘토로서 참여하고 있으니, 관심 있는 분들은 많은 참여 부탁드립니다!

https://www.oss.kr/contribution_academy_notice/show/c7a602c6-4211-4652-a517-f6618f0fd712

@songbirds 어서 지원하세요

@antolius Great question! For prototyping with custom vocabulary, we're setting up automated PR builds that will solve exactly this use case.

Soon, each pull request will automatically publish versioned builds to JSR and npm. For example, PR #123 would generate releases like:

• First push: 1.6.0-pr.123.1
• Second push: 1.6.0-pr.123.2
• And so on…

This means you can install and test vocabulary extensions before they're merged upstream:

npm install @fedify/fedify@1.6.0-pr.123.1

This approach lets you prototype with your custom object types immediately while contributing back to the community when ready. You can develop against the PR build, and once your vocabulary addition is merged, simply update to the stable release.

The build pipeline isn't quite ready yet, but it's coming soon. In the meantime, forking and building locally is still your best bet for custom vocabulary during prototyping.

@fedify this sounds reasonable for extending support for 3rd party vocabulary. How do you envision developing 1st party vocab for servers implemented using fedify?

For example, I'm developing a service that needs to introduce some new object types. But I'm nowhere near ready to codify them in a FEP or share them with broader fedify userbase. What would be the best way to continue using fedify in this prototyping phase? (Perhaps building with a fedify fork and merge uspream once server is done?)

While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.

Fedify accepts vocabulary contributions when they meet any of these criteria:

• Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
• Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
• Thoroughly discussed within the Fedify community (Discord, Matrix, GitHub Discussions)

Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.

This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.

For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.

#fedidev

Add rendering of quote posts in web UI by diondiondion · Pull Request (#34738) · mastodon/mastodon · GitHub
https://github.com/mastodon/mastodon/pull/34738

@S_H_

$ RAILS_ENV=development bin/rails dev:populate_sample_data

するとdevelopment環境で引用つきの投稿の例を見られますよ〜

fedify node (ActivityPub판 neofetch 같은 것) 커맨드로 Hackers' Pub 서버를 찔러봤다.

 ██████████████████████████████████████  hackers.pub
 ██████████████████████████████████████  ===========
 ██████████████████████████████████████  Software:
 ██████████████████████████████████████    hackerspub v0.1.0+0972cbb086b1f01e039221a3c8522fc4b8d0b4b8
 ██████████████████████████████████████    https://hackers.pub/
 ▒▒▒▓▓████▓▒▒▓▓████████▓▓▒░▒▒░@##@░▓▓██    https://github.com/hackers-pub/hackerspub
 ppbkM@█▓▒*mp%#▒█████▓░BowZphZXXUJCLdW#  Protocols:
 JJLOk#█▓░dzJb&&&*kbhahhqQCOwJuXZpLvJmp    activitypub
 XXzcQb*ohCfcq*pQLLQZqbhhkbqZCzQoMZuXCQ  Outbound services:
 XzxtnULCJx)xwaQnzCOphMB@▒#aZUxzOqLvCqk    atom1.0
 XXcvCpakdUtvpMkqLccU0h#▒▓@aZc|/uJOq*#▓  Users:
 XXJLd8▓▒@qnXpWB@8WdYjCkM░@aZLXO%▒▒▓▓██    244 (total)
 Q0Zwa#█▓░kUQk%km0CYccmM#▒░%dw0d8██████    24 (active half year)
 MMW&#▒██▓B*MB#&*akkho&░▒▓▓@8&M8░██████    5 (active month)
 ▓▓▓▓██████▓▓██▓▓▒░░▒▓▓█████▓▓▓▓███████  Local posts: 
 ██████████████████████████████████████    3,946
 ██████████████████████████████████████  Local comments:
 ██████████████████████████████████████    0
 ██████████████████████████████████████  Open registrations:
                                           No

#FedifyNode

Hackers' Pubというソフトウェア開発者向けのSNS兼ブログプラットフォームを開発しています。ActivityPubに対応しており、MastodonやMisskeyなどとも相互にコミュニケーションが可能です。まだユーザー数は少ないですが、質の高い記事が投稿されています。

また、これまでは韓国語中心のコミュニティが形成されていますが、今後は日本語コミュニティも拡大していきたいと考えています。自動翻訳機能が搭載されているため、既存の韓国語の記事も日本語で読むことができます。

ご興味のある方は、DMでメールアドレスをお知らせいただければご招待いたします！

Hackers' Pub이라는 소프트웨어 개발자를 위한 SNS 겸 블로그 플랫폼을 만들고 있습니다. ActivityPub을 지원하여 Mastodon이나 Misskey 등과도 상호 소통이 가능합니다. 아직 사용자 수는 적지만 괜찮은 글들이 올라옵니다. 관심 있으신 분은 DM으로 이메일 주소 알려주시면 초대 드립니다!

Following on from today's earlier PR to @hollo, I've gone ahead and implemented PKCE for OAuth in Hollo

So now they too can have more security for OAuth authorization code grant flows.

(Also added a tonne of extra test coverage)

https://github.com/fedify-dev/hollo/pull/155

@thisismissem By the way, thanks for your great work as always!

@thisismissem FYI, Vitest has its official Mastodon account: @vitest.