Following
Public ActivityPub posts from actors connected with @me@changkyun.kim.
來日(내일) 午前(오전) 9時(시)에 臺北行(타이베이행) 飛行機(비행기)를 타야 하는데, 아직 짐을 못 쌌다… 🙄
@silverpill Since this is a roadmap for about a year from now, it's not very specific yet, but it will likely involve providing test harnesses for the major FEPs.
光栄なことに、DrFed（@drfed）チームを代表して、APC（@APC、Association for Progressive Communications）の『自由な未来のインターネット作り』（Building a Free Internet of the Future）インタビューシリーズにお答えすることになりました。（英語） https://www.apc.org/en/news/drfed-reducing-complexity-and-enabling-more-people-shape-fediverse
榮光(영광)스럽게도 @drfed 팀을 代表(대표)하여 @APC (Association for Progressive Communications) 웹사이트의 《自由(자유)로운 未來(미래) 인터넷 만들기》(Building a Free Internet of the Future) 인터뷰 시리즈에 答(답)하게 되었습니다 (英文(영문)). https://www.apc.org/en/news/drfed-reducing-complexity-and-enabling-more-people-shape-fediverse
It is an honour to have been interviewed on behalf of the @drfed team for @APC's Building a Free Internet of the Future series. https://www.apc.org/en/news/drfed-reducing-complexity-and-enabling-more-people-shape-fediverse
@lutindiscret @kosmo I have no idea. @robin_maki Does it?
A friend of mine just launched Kosmo, a new #fediverse service out of Korea, built around the dōjin (同人) scene: fan works, fanzines, that whole self-published creative culture. It's live now at kos.moe, in open beta and Korean-language only for now. It speaks #ActivityPub, so you get the basics: posting, following, boosting. It also has emoji reactions, and one account can hold several public profiles. They say profile tags are coming next, meant to express something about a profile's identity and usable for search and muting too. It's still early, and they'd genuinely appreciate feedback from anyone who gives it a try. #fedidev #doujin #dōjin #subculture #otaku RE: https://planet.moe/@kosmo/117014381597184627
LogTape 2.3.0 is out. withConfig(): scoped, temporary logging policies—handy for tests and request-local debug outputcreateFailureLogReporter(): test logs shown only on failure, plus Node.js/Deno/Bun/Vitest packagesNew @logtape/graphql-yoga integrationSentry 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. RE: https://sonomu.club/@threedaymonk/117003149872786256
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.
中國語(중국어)로 「키보드 워리어」를 「鍵盤俠(건반협)」이라고 부른다는 걸 오늘 알게 되었다. 너무 재밌는 말이라 韓國語(한국어)로 輸入(수입)하고 싶을 程度(정도)이다.
And that's how I ended up with about 30 domains. 😂 RE: https://social.treehouse.systems/@dysfun/116833355517782166
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.
@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.
@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. RE: https://hollo.social/@hongminhee/019f5e9e-cdd7-7d7d-9438-12f7ee68ed1f
@evan @siliconsjang Oh, yes! I once introduced SiliconBeest before! RE: https://hollo.social/@hongminhee/019e24d6-fcbd-7c5b-b6a9-902ed412a777
Just created my CodeFloe account! https://codefloe.com/hongminhee RE: https://social.tchncs.de/@codefloe/116963861098218609
Optique, a type-safe combinatorial CLI parser for TypeScript, just shipped 1.2.0. Modifiers are chainable now: option(…).map(…).withDefault(…). deferredValue() defers a fallback until the handler asks for it. Four new packages: @optique/prompt@optique/clack@optique/standard-schema@optique/derived-defaults @optique/discover gains lifecycle hooks and a static-module generator, and optique.dev has a new look. https://github.com/dahlia/optique/discussions/877
