洪 民憙 (Hong Minhee)

@bootlegrydia That's also interesting!

@hongminhee seems in northeast china's korean language it's 건반군 (鍵盤軍? 君? dunno which one it is)

mw.jl.gov(dot)cn/xxgk/tzgg/202412/W020241218543067361444.pdf

LogTape 2.3.0 is out.

• withConfig(): scoped, temporary logging policies—handy for tests and request-local debug output
• createFailureLogReporter(): test logs shown only on failure, plus Node.js/Deno/Bun/Vitest packages
• New @logtape/graphql-yoga integration
• Sentry sink: route logs vs. breadcrumbs by level

https://github.com/dahlia/logtape/discussions/197

Read why's (poignant) Guide to Ruby and Dave Thomas's Pragmatic Programmer in high school in the mid-2000s and got obsessed. I went looking for a Rails shop for my first job. I loved that Ruby had Perl's hacker spirit and Smalltalk's elegant object system.

I moved on to other languages a few years later. Almost twenty years on, reading about the far-right politics of some of Ruby's most powerful people just makes me sad.

It doesn’t matter whether “Matz is nice”
https://po-ru.com/2026/07/29/it-doesnt-matter-whether-matz-is-nice
#ruby #blog

ActivityPub assumes content is text/html by default when mediaType isn't specified, whether the object is a Note or an Article. Misskey does something different, for reasons I still don't fully understand. It stores its internal representation as MFM, its own markup language. Between Misskey instances, it sends that through a separate _misskey_content property rather than content itself. When talking to non-Misskey software, it converts HTML into MFM.

The trouble is that MFM can represent much less than HTML. If another implementation sends HTML that has no clean MFM equivalent, the formatting comes out mangled in Misskey.

I keep wondering why Misskey didn't just store HTML, like Mastodon and most other implementations do, or at least kept both the source markup and the rendered HTML side by side. I know storing only HTML can lose some MFM features too. I still don't understand why Misskey chose the format that can represent less.

The more that I use #optique by @hongminhee, the more impressive the #typescript CLI parser is. It's clearly a CLI framework.

Like I just found you can do man pages! 🤯 I'm now navigating more to see what other secrets this has. 😎

https://optique.dev/

SOCIALISTS AREN’T NAIVE ABOUT HUMAN NATURE https://jacobin.com/2026/07/socialism-human-nature-morality

中國語(중국어)로 「키보드 워리어」를 「鍵盤俠(건반협)」이라고 부른다는 걸 오늘 알게 되었다. 너무 재밌는 말이라 韓國語(한국어)로 輸入(수입)하고 싶을 程度(정도)이다.

@mdione Exactly! 😂

@hongminhee the people at the dot pub NIC have two yachts named "The Evan Prodromou" and "The Hong Minhee"

And that's how I ended up with about 30 domains. 😂

Domain Driven Development (DDD) - buying a domain name to attempt to force yourself to write the software it's for.

ActivityPubでちゃんと地震速報配信するなら、常にフォロワーが居る全サーバーのinboxに1セッション繋いだまま、いつでもデータを送れる状態で待機しとくしかないよ。

Some amusing timing: Vercel Labs just published scriptc, with a strikingly similar surface goal: compile JavaScript/TypeScript ahead of time to a small native executable, with no Node.js or V8 embedded. Apparently someone else wandered into roughly the same problem at roughly the same time. The design underneath is almost the opposite bet, though.

scriptc runs the real TypeScript 7 checker and treats its results as facts, lowering them into a typed IR with monomorphic arrays, exact records, tagged unions, and so on, then through LLVM or a C fallback. Anything outside that model, including any and plain JavaScript packages, needs --dynamic, which links QuickJS-ng as a separate island with its own heap and microtask queue. Values are copied and checked at the boundary. Its correctness evidence is 800+ differential tests against Node.js, rather than a spec-conformance claim.

Oseo trusts none of that. A value annotated number may still be a string at runtime, and the compiled generic path has to handle it without an escape-hatch VM. Typed and untyped code use the same native generic-plus-guarded model, and the target is versioned ECMA-262/test262 conformance rather than matching Node.js behavior. scriptc trusts the checker and isolates what it doesn't trust in another engine; Oseo trusts nothing, but has no second engine to isolate it into. scriptc is already a much broader, more mature Vercel Labs project. I just find the near-convergence from opposite directions rather pleasing.

Filip Jerzy Pizło, Fil-C's author and someone who makes dynamic languages fast for a living, left a fairly harsh critique of scriptc on Hacker News, worth reading in full. His core complaints, QuickJS-ng as the any fallback and floats-only numbers without integer inference, land on exactly the two bets Oseo refuses to make: a guard failure here falls through to already-compiled generic code, not an interpreter, and there's no static gamble on numeric representation to begin with.

@jkb I'm not entirely sure about North America, but in East Asia—at least in Korea—generative AI is already being used a lot in the arts and commercial advertising, and it seems like typical office workers are using LLMs quite a bit as well.

I get the impression that people are more open to generative AI like LLMs in North America than in Europe, and even more so in East Asia than in North America, and I'm curious as to why that is.

This FEP introduces Emoji Catalog, which provide a way for both clients and servers to publish and discover custom emoji.

ActivityPub implementations, including Mastodon, commonly support custom emoji. FEP-9098 defines how an Emoji is embedded in an Activity Streams object, but it does not define how a client discovers the emoji available for use when composing new content.

This leads to ActivityPub clients relying on implementation-specific APIs such as the Mastodon custom emoji endpoint.

A standardized emoji catalog allows a C2S client to:

• Populate an emoji picker.
• Determine which emoji the authenticated actor may use.
• Retrieve emoji categories and static previews.
• Update its local cache when the catalog changes.

Additionally, a standardized emoji catalog allows servers to publish custom emoji that other ActivityPub implementations can discover reliably.

Read full FEP at https://codeberg.org/fediverse/fep/pulls/888

hot take, EVERY activitypub implementation should build an OICD connector just as #gotosocial https://docs.gotosocial.org/en/latest/configuration/oidc/

why you say?

Imagine using my mastodon account in any server to login in any other mastodon server, pixelfed, lemmy, you name it ... single login

@bgl Yep, aware of Static Hermes. The big difference is that its annotations define a sound, stricter language: typed arrays aren't ordinary JavaScript arrays, and once something's annotated, that annotation is enforced, not just advisory. In Oseo an annotation is only a hint; a number can still turn out to be a string at runtime, and the compiled generic path has to handle that correctly regardless. Static Hermes also still routes untyped code through Hermes's own interpreter and JIT tiers, so it's really two systems stitched together. Oseo has no VM tier at all: typed and untyped values share one JavaScript semantics, and annotations only pick which already-compiled native path runs. Different platform too: Static Hermes lives inside React Native's engine, Oseo is aiming to be a self-contained native binary, server-side for now.

分散ネットワークにおける決済の手段として暗号通貨は自然な選択肢の一つだと思うけど（Fediverseのサーバを跨ぐやり取りで特定のプラットフォーム（たとえそれがOpen Collectiveだったとしても）をハードコードするわけにはいかないだろうし）、ホストしているサービスの規約の都合からFEPチームの意思によらずFEPで暗号通貨に言及できなくなるというのは深刻なリスクでは

inspired by CLAUDE.md, I’ve started putting markdown files named after coworkers into work code repos so I can remind them to stop doing shit to the codebase that annoys me

for some reason they’re all mad at me now, which means ill be adding commands to JEREMY.md for an attitude adjustment

Open Weights and American AI Leadership https://lobste.rs/s/gqgbrz #ai
https://www.microsoft.com/en-us/corporate-responsibility/topics/open-weight/

Fedifyあるから今は比較的楽なんじゃないかしら、自作AP(TS限定だけど)
https://github.com/fedify-dev/fedify

https://thonny.org

is it good for iot education (rpi)

@bgl Different goals, really. AssemblyScript is its own statically-typed language that happens to look like TypeScript: it accepts a strict subset of the syntax, wants explicit types like i32/f64 rather than dynamic values, and doesn't implement JavaScript's actual object and prototype semantics. You write new code specifically within those constraints to get compact WebAssembly out. Oseo is trying to keep full ECMA-262 dynamic semantics, arbitrary shapes, any, all of it, and still reach native code, with types and JSDoc used only as opt-in hints that fall back to a compiled generic path whenever they're wrong. AssemblyScript trades JavaScript semantics for a clean path to WebAssembly; Oseo is betting it doesn't have to make that trade. Similar-looking syntax, close to opposite premises.

That JavaScript/TypeScript runtime idea I mentioned has mutated a bit.

Once I actually thought about it, writing another Node.js/Deno/Bun-shaped runtime didn't seem especially useful; there are enough of those already. What I actually want to try is an ahead-of-time JavaScript/TypeScript compiler in roughly the SBCL/Chez Scheme tradition: native code, with a generic implementation always available and specialized versions picked by cheap runtime guards. A failed guard just falls through to code that's already compiled, rather than needing an interpreter or a deopt path. There are probably adjacent projects doing pieces of this, so I won't claim the territory is empty, but I haven't seen this exact shape applied to JavaScript/TypeScript. I've codenamed it Oseo (鼯鼠; flying squirrel in Sino-Korean).

It's still just a compiler experiment, not something I'd call presentable yet, so the repo stays closed for now. Once it works well enough, the first thing I want to try is switching the Fedify CLI, currently built with deno compile, over to Oseo and seeing what breaks. Fedify is the ActivityPub server framework I also maintain, so it should make a reasonably unforgiving first customer. I'll keep picking at Oseo for the next few months and post again when something interesting starts working.

Major updates were made to the delightful fediverse curated lists..

💎 delightful fediverse experience

- 52 new projects added
- 50 projects marked unmaintained
- 15 projects updated

New list categories:

- Professional networks
- Instant messaging
- Search engines
- Security and privacy

https://delightful.coding.social/delightful-fediverse-experience

💎 delightful fediverse development

- 18 new projects added
- 20 projects marked unmaintained
- 5 projects updated
- 7 projects removed
- Improved table of contents
- Listed SWICG / SocialCG task forces
- More improvements pending

New list categories:

- SWICG Task forces
- Data portability
- Developer hubs
- Data formats

https://delightful.coding.social/delightful-fediverse-development

💎 delightful fediverse clients

- 16 new projects added
- 33 projects marked unmaintained
- 5 projects updated
- 3 projects removed
- Separate section for unmaintained

https://delightful.coding.social/delightful-fediverse-clients

#ActivityPub #SocialWeb #fediverse

"artist-alley implements ArchivePub, an open federation protocol built on the ActivityPub data model with DAM-shaped extensions for asset sharing, workflow state, and brand workspaces."

"Content-addressed federation:
Every reference to asset bytes uses a content-addressed URI:
cas://<sha256>?content-type=image/png&size=12345"

https://artist-alley.org/docs/archivepub
#ActivityPub #fedidev #ArchivePub