home.social

Search

343 results for “hongminhee”

  1. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    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

    #fep #fedidev #fediverse #activitypub
  2. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.

    https://github.com/fedify-dev/fedify/pull/631

    #fedidev #ActivityPub #JSONLD

    #fedify #jsonld #fedidev #activitypub
  3. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    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

    #fedify #jsonld #fedidev #activitypub
  4. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    In addition to Date, which has millisecond precision, I hope that Drizzle ORM also supports Temporal.Instant, which has nanosecond precision. 😢

    #JavaScript #Date #Temporal #Drizzle #DrizzleORM

    #date #drizzle #temporal #drizzleorm #javascript
  5. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    If you'd like to preview the #tutorial I'm writing on building a small #threadiverse software with #Fedify, here it is:

    https://pr-710.fedify.pages.dev/tutorial/threadiverse

    If you'd like to give feedback after reading it, please leave a comment on the following PR:

    https://github.com/fedify-dev/fedify/pull/710

    #fedify #tutorial #threadiverse
  6. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Writing a #Fedify tutorial on creating #threadiverse software…

    #fedify #threadiverse
  7. 洪 民憙 (Hong Minhee) @[email protected] ·

    #Optique 1.0.0 is out! I built it as a #TypeScript #CLI parser in the style of optparse-applicative: compose small typed parsers, TypeScript infers the result. New in 1.0: @optique/env for environment variable fallbacks and @optique/inquirer for Inquirer.js prompts.

    Optique 1.0.0: environment var...

    #optique #typescript #cli
  8. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Optique just crossed 600 GitHub stars!

    For those unfamiliar: #Optique is a #CLI parsing library for #TypeScript that takes a parser combinator approach, inspired by Haskell's optparse-applicative. The core idea is “parse, don't validate”—you express constraints like mutually exclusive options or dependent flags through types, and TypeScript infers the rest automatically. No runtime validation boilerplate needed.

    It started as something I built out of frustration while working on Fedify, an ActivityPub framework, when no existing CLI library could express the constraints I needed in a type-safe way. Apparently I wasn't the only one who felt that way.

    Thank you all for the support.

    https://github.com/dahlia/optique

    #cli #optique #typescript
  9. 洪 民憙 (Hong Minhee) @[email protected] ·

    #Optique 1.0.0 preview: runWithConfig() is gone—run() now accepts source contexts. Meta command config gets independent command/option sub-configs. bindConfig() gains config-file metadata for path resolution. #TypeScript #CLI

    dahlia/optique

    #optique #typescript #cli
  10. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    #Optique 1.0.0 is shaping up, and three API changes are worth knowing about in advance.

    • Runner consolidation: run() from @optique/run now accepts source contexts directly, which makes runWith() and runWithConfig() redundant for most use cases. runWithConfig() is removed outright—no deprecation, since we have a major version to absorb the break. For the typical CLI, run() is now the single entry point.

    • Meta command config redesign: help, version, and completion in RunOptions no longer use mode: "command" | "option" | "both". Each now takes independent command and option sub-configs, which makes it possible to give --help a -h alias, hide a meta command from usage lines while keeping it in the help listing, or group the command and option forms differently. String shorthands (help: "both", version: "1.2.3", etc.) still work exactly as before.

    • Config-file-relative paths: bindConfig()'s key callback now receives config file metadata as a second argument—configDir and configPath—so you can resolve paths relative to the config file's location rather than the working directory. This matches how tools like the TypeScript compiler handle outDir and similar path options.

    More details on the 1.0.0 milestone.

    #optique
  11. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    #Optique 0.9.0 is here!

    This release brings #async/await support to #CLI parsers. Now you can validate input against external resources—databases, APIs, Git repositories—directly at parse time, with full #TypeScript type safety.

    The new @optique/git package showcases this: validate branch names, tags, and commit SHAs against an actual Git repo, complete with shell completion suggestions.

    Other highlights:

    • Hidden option support for deprecated/internal flags
    • Numeric choices in choice()
    • Security fix for shell completion scripts

    Fully backward compatible—your existing parsers work unchanged.

    https://github.com/dahlia/optique/discussions/75

    #cli #async #optique #typescript
  12. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

    The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

    I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

    https://github.com/dahlia/optique/issues/52

    #optique #typescript
  13. 洪 民憙 (Hong Minhee) @[email protected] ·

    CLIパーサーの新しい記事を書きました。--reporterの値によって--output-fileが必須になったり禁止になったり…そういう関係、型で表現できたら楽じゃないですか？ #TypeScript #CLI #Optique

    CLIのオプション分岐、もうif文は書かなくていい

    #typescript #cli #optique
  14. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Interesting design question for #Optique (a type-safe #CLI parser for #TypeScript): how should it handle unrecognized options in wrapper/proxy tools? Proposed three modes but wondering if the complexity is worth it. Thoughts?

    https://github.com/dahlia/optique/issues/35

    #cli #optique #typescript
  15. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Just shared my thoughts on #JavaScript library #logging on Hacker News. Explores the fragmentation problem and dependency dilemmas from a library author's perspective. Would love to hear feedback from the #winston/#Pino users.

    https://news.ycombinator.com/item?id=44351881

    #pino #logging #winston #javascript
  16. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    A daily minor annoyance: #GFM (GitHub Flavored Markdown) breaking standard #Markdown behavior by rendering single newlines as <br>.

    If you're used to formatting plain text with hard wraps for mailing lists, you know the pain. You type up a perfectly readable 80-column text block, hit submit, and realize #GitHub has turned it into a jagged mess of arbitrary line breaks. I really miss standard Markdown paragraph collapsing in issue trackers.

    #gfm #github #markdown
  17. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

    The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

    This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

    https://github.com/fedify-dev/fedify/issues/754

    #ActivityPub #Fedify #fediverse #fedidev

    #c2s #fedify #fedidev #fediverse #activitypub
  18. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Today @kopper 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

    #c2s #fedidev #fediverse #activitypub
  19. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Unless something comes up, #Fedify 2.2.0 will be released today.

    #fedify
  20. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Honestly, I don't really care what strategy other #ActivityPub implementations follow to comply with the spec. (I solved it in #Fedify by just using a proper JSON-LD processor.) It's just a bit annoying that I always send valid JSON-LD documents, but whenever I encounter an interoperability bug where the other side can't process them, I'm the one who has to send them a patch to fix it. 😩

    #fedify #activitypub
  21. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    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

    #fedify #fedidev #fediverse #activitypub
  22. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    Introducing #Upyo!

    A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

    Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

    https://upyo.org/

    #bun #jsr #npm #deno #node #smtp
  23. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知り合いの @siliconsjang さんが今日、SiliconBeest v1.0.0 を公開しました。Cloudflare Workers、D1、R2、Queuesだけで動くフェディバースサーバーで、Fedifyを使ってくれています。

    個人的に面白いと思ったのは出発点で、Cloudflare障害のたびにフェディバースのサーバーがまとめて落ちるのを見て、「それならいっそCloudflareの上で動かせばよいのでは」と思ったのが始まりだそうです。

    小規模なインスタンスならCloudflareの無料プランで、少し大きくなっても月5ドルくらいで運営できることを目指しているとのこと。まだ初期バージョンなので未実装の部分も多く、MastodonやMisskey APIとの互換性は未だ先の目標みたいです。

    Fedifyを使ってくれているのもあって、個人的に嬉しいです。気になったので共有します。

    ソースコードはAGPL 3.0でGitHubで公開されています。

    #フェディバース #fediverse #ActivityPub #Cloudflare

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #fediverse #cloudflare #activitypub #フェディバース
  24. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知り合いの @siliconsjang さんが今日、SiliconBeest v1.0.0 を公開しました。Cloudflare Workers、D1、R2、Queuesだけで動くフェディバースサーバーで、Fedifyを使ってくれています。

    個人的に面白いと思ったのは出発点で、Cloudflare障害のたびにフェディバースのサーバーがまとめて落ちるのを見て、「それならいっそCloudflareの上で動かせばよいのでは」と思ったのが始まりだそうです。

    小規模なインスタンスならCloudflareの無料プランで、少し大きくなっても月5ドルくらいで運営できることを目指しているとのこと。まだ初期バージョンなので未実装の部分も多く、MastodonやMisskey APIとの互換性は未だ先の目標みたいです。

    Fedifyを使ってくれているのもあって、個人的に嬉しいです。気になったので共有します。

    ソースコードはAGPL 3.0でGitHubで公開されています。

    #フェディバース #fediverse #ActivityPub #Cloudflare

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #fediverse #cloudflare #activitypub #フェディバース
  25. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知り合いの @siliconsjang さんが今日、SiliconBeest v1.0.0 を公開しました。Cloudflare Workers、D1、R2、Queuesだけで動くフェディバースサーバーで、Fedifyを使ってくれています。

    個人的に面白いと思ったのは出発点で、Cloudflare障害のたびにフェディバースのサーバーがまとめて落ちるのを見て、「それならいっそCloudflareの上で動かせばよいのでは」と思ったのが始まりだそうです。

    小規模なインスタンスならCloudflareの無料プランで、少し大きくなっても月5ドルくらいで運営できることを目指しているとのこと。まだ初期バージョンなので未実装の部分も多く、MastodonやMisskey APIとの互換性は未だ先の目標みたいです。

    Fedifyを使ってくれているのもあって、個人的に嬉しいです。気になったので共有します。

    ソースコードはAGPL 3.0でGitHubで公開されています。

    #フェディバース #fediverse #ActivityPub #Cloudflare

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #フェディバース #activitypub #cloudflare #fediverse
  26. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知り合いの @siliconsjang さんが今日、SiliconBeest v1.0.0 を公開しました。Cloudflare Workers、D1、R2、Queuesだけで動くフェディバースサーバーで、Fedifyを使ってくれています。

    個人的に面白いと思ったのは出発点で、Cloudflare障害のたびにフェディバースのサーバーがまとめて落ちるのを見て、「それならいっそCloudflareの上で動かせばよいのでは」と思ったのが始まりだそうです。

    小規模なインスタンスならCloudflareの無料プランで、少し大きくなっても月5ドルくらいで運営できることを目指しているとのこと。まだ初期バージョンなので未実装の部分も多く、MastodonやMisskey APIとの互換性は未だ先の目標みたいです。

    Fedifyを使ってくれているのもあって、個人的に嬉しいです。気になったので共有します。

    ソースコードはAGPL 3.0でGitHubで公開されています。

    #フェディバース #fediverse #ActivityPub #Cloudflare

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #fediverse #cloudflare #activitypub #フェディバース
  27. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知人(지인)인 @siliconsjang 님이 오늘 SiliconBeest v1.0.0을 公開(공개)했습니다. Fedify와 Cloudflare를 基盤(기반)으로 만든 #聯合宇宙(연합우주) 소프트웨어인데, Workers, D1, R2, Queues 등 #Cloudflare 서버리스 스택 위에서 全部(전부) 돌아갑니다.

    發想(발상)의 出發點(출발점)이 재밌습니다. Cloudflare 障礙(장애) 때 聯合宇宙(연합우주) 서버들이 덩달아 다운되는 걸 보고, 「그럼 아예 Cloudflare 위에서 돌리면 되지 않나?」라는 생각에서 始作(시작)했다고 하네요.

    費用(비용) 面(면)에서는 小規模(소규모) 인스턴스는 Cloudflare 無料(무료) 플랜, 조금 더 큰 規模(규모)는 月(월) $5 플랜으로 堪當(감당)할 수 있도록 하는 게 目標(목표)라고 합니다. 아직 初期(초기) 버전이라 未具顯(미구현) 機能(기능)이 많고, Mastodon 및 Misskey API 互換(호환)은 長期(장기) 目標(목표)로 보고 있다네요.

    Fedify를 써주시는 분이라 반갑기도 하고, 應援(응원)하고 싶어 紹介(소개)합니다.

    소스 코드는 AGPL 3.0으로 GitHub에 공개되어 있습니다.

    #ActivityPub #연합우주 #페디버스

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #cloudflare #activitypub #聯合宇宙 #연합우주 #페디버스
  28. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知人(지인)인 @siliconsjang 님이 오늘 SiliconBeest v1.0.0을 公開(공개)했습니다. Fedify와 Cloudflare를 基盤(기반)으로 만든 #聯合宇宙(연합우주) 소프트웨어인데, Workers, D1, R2, Queues 등 #Cloudflare 서버리스 스택 위에서 全部(전부) 돌아갑니다.

    發想(발상)의 出發點(출발점)이 재밌습니다. Cloudflare 障礙(장애) 때 聯合宇宙(연합우주) 서버들이 덩달아 다운되는 걸 보고, 「그럼 아예 Cloudflare 위에서 돌리면 되지 않나?」라는 생각에서 始作(시작)했다고 하네요.

    費用(비용) 面(면)에서는 小規模(소규모) 인스턴스는 Cloudflare 無料(무료) 플랜, 조금 더 큰 規模(규모)는 月(월) $5 플랜으로 堪當(감당)할 수 있도록 하는 게 目標(목표)라고 합니다. 아직 初期(초기) 버전이라 未具顯(미구현) 機能(기능)이 많고, Mastodon 및 Misskey API 互換(호환)은 長期(장기) 目標(목표)로 보고 있다네요.

    Fedify를 써주시는 분이라 반갑기도 하고, 應援(응원)하고 싶어 紹介(소개)합니다.

    소스 코드는 AGPL 3.0으로 GitHub에 공개되어 있습니다.

    #ActivityPub #연합우주 #페디버스

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #cloudflare #activitypub #聯合宇宙 #연합우주 #페디버스
  29. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知人(지인)인 @siliconsjang 님이 오늘 SiliconBeest v1.0.0을 公開(공개)했습니다. Fedify와 Cloudflare를 基盤(기반)으로 만든 #聯合宇宙(연합우주) 소프트웨어인데, Workers, D1, R2, Queues 등 #Cloudflare 서버리스 스택 위에서 全部(전부) 돌아갑니다.

    發想(발상)의 出發點(출발점)이 재밌습니다. Cloudflare 障礙(장애) 때 聯合宇宙(연합우주) 서버들이 덩달아 다운되는 걸 보고, 「그럼 아예 Cloudflare 위에서 돌리면 되지 않나?」라는 생각에서 始作(시작)했다고 하네요.

    費用(비용) 面(면)에서는 小規模(소규모) 인스턴스는 Cloudflare 無料(무료) 플랜, 조금 더 큰 規模(규모)는 月(월) $5 플랜으로 堪當(감당)할 수 있도록 하는 게 目標(목표)라고 합니다. 아직 初期(초기) 버전이라 未具顯(미구현) 機能(기능)이 많고, Mastodon 및 Misskey API 互換(호환)은 長期(장기) 目標(목표)로 보고 있다네요.

    Fedify를 써주시는 분이라 반갑기도 하고, 應援(응원)하고 싶어 紹介(소개)합니다.

    소스 코드는 AGPL 3.0으로 GitHub에 공개되어 있습니다.

    #ActivityPub #연합우주 #페디버스

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #페디버스 #연합우주 #聯合宇宙 #activitypub #cloudflare
  30. 洪 民憙 (Hong Minhee) :nonbinary: @[email protected] ·

    知人(지인)인 @siliconsjang 님이 오늘 SiliconBeest v1.0.0을 公開(공개)했습니다. Fedify와 Cloudflare를 基盤(기반)으로 만든 #聯合宇宙(연합우주) 소프트웨어인데, Workers, D1, R2, Queues 등 #Cloudflare 서버리스 스택 위에서 全部(전부) 돌아갑니다.

    發想(발상)의 出發點(출발점)이 재밌습니다. Cloudflare 障礙(장애) 때 聯合宇宙(연합우주) 서버들이 덩달아 다운되는 걸 보고, 「그럼 아예 Cloudflare 위에서 돌리면 되지 않나?」라는 생각에서 始作(시작)했다고 하네요.

    費用(비용) 面(면)에서는 小規模(소규모) 인스턴스는 Cloudflare 無料(무료) 플랜, 조금 더 큰 規模(규모)는 月(월) $5 플랜으로 堪當(감당)할 수 있도록 하는 게 目標(목표)라고 합니다. 아직 初期(초기) 버전이라 未具顯(미구현) 機能(기능)이 많고, Mastodon 및 Misskey API 互換(호환)은 長期(장기) 目標(목표)로 보고 있다네요.

    Fedify를 써주시는 분이라 반갑기도 하고, 應援(응원)하고 싶어 紹介(소개)합니다.

    소스 코드는 AGPL 3.0으로 GitHub에 공개되어 있습니다.

    #ActivityPub #연합우주 #페디버스

    RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

    #cloudflare #activitypub #聯合宇宙 #연합우주 #페디버스
Next page