洪 民憙 (Hong Minhee)

@evan @cwebber @kopper @hongminhee Couldn’t we agree to standardize on expanded json-ld? We would not need any json-ld processor, we would not need to fetch or cache any context. There would be no way to shadow properties.

@kopper @evan @cwebber Ah, yes, the https://w3id.org/identity/v1 context... As I recall, I probably used it because I needed some kind of context to handle Linked Data Signatures. It's a bit embarrassing, but Fedify also preloads and uses that context. Personally, I wish https://w3id.org/identity/v1 would redirect to a different URL instead of the now-defunct https://web-payments.org/contexts/identity-v1.jsonld.

Nice that @kagihq Translate is available on iOS now. Using it as my new default.

https://apps.apple.com/se/app/kagi-translate/id6748310237?l=en-GB

@kopper @hongminhee As the person probably most responsible for making sure json-ld stayed in the spec (two reasons: because it was the only extensibility answer we had, and because we were trying hard to retain interoperability with the linked data people, which ultimately did not matter), I agree with you. I do ultimately regret not having a simpler solution than json-ld, especially because it greatly hurt our ability to sign messages, which has considerable effect on the ecosystem.

Mea culpa :\

I do think it's fixable. I'd be interested in joining a conversation about how to fix it.

One of the most interesting areas of exploration in the ActivityPub community right now is the ActivityPub API. Most people who know ActivityPub are familiar with its federation protocol, which lets social networking servers like Mastodon and Pixelfed share data between them. But there is another, closely-related feature in the same specification, called the "social API".

ActivityPub has five normative sections: 3 Objects, 4 Actors, 5 Collections, 6 Client-to-Server Interactions, and 7 Server-to-Server Interactions. 3, 4, and 5 provide a read-only interface to social data that is useful for both the federation protocol and the social API. It lets both clients and servers read information about users on the network, their feeds, and the things they make and share.

Section 6 is focused on the mechanism clients can use to create new activities, and the side-effects of those activities. "Activities" are the most important data structure in ActivityPub (which is why they're featured so prominently in the name!). They represent sentences or statements about things that happen on a social network, like "Christine created the image img123.jpg" or "Evan liked Christine's image img123.jpg" and "Amy shared Christine's image img123.jpg". Creating these statements is how clients can make things happen with ActivityPub.

Section 7 is focused on how and when servers can send these activities across the network to other servers. There are some side-effects that are laid out, but mostly they involve cache management.

So, here's the important point I want to make: the federation protocol which connects ActivityPub servers is defined in sections 3, 4, 5, and 7. The social API is defined in sections 3, 4, 5, and 6. But some people use "server-to-server" or "s2s" as a synonym for the federation protocol, even though "server to server interactions" only covers one section. Similarly, some people use "c2s" or "client-to-server" as a synonym for the social API, even if "client-to-server interactions" is only one section.

I prefer to use "social API" or "ActivityPub API" to refer to the entire part of ActivityPub that lets client apps talk to social servers. Here are some rough reasons why.

• It's what the spec calls it. In the conformance section, we said that 'this specification defines two closely related and interacting protocols: A client to server protocol, or "Social API" [...] A server to server protocol, or "Federation Protocol"'. This was intentional; the names come from the Social Web Working Group charter deliverables. Making a Social API was a key goal of the group. The ActivityPub API satisfies that goal.
• It's a term that all developers and many users are familiar with. People who've used mobile apps or third-party apps know what an API is and what it's for. If you use "c2s", it's not clear to most developers what you're even talking about.
• It's accurate. The social API is a RESTful API that uses JSON, HTTP, and all the fun stuff that app developers are already familiar with.
• It emphasizes what's already available. People often say that Mastodon does not implement the ActivityPub API. But it implements sections 3, 4, and 5 of the specification – it has to, in order to support the federation protocol. That's the entire read-only side of the API. All (almost all?) Fediverse servers support these parts of the spec, too. You can build a pretty OK read-only API client using what's already available from Mastodon and others; see https://acct.swf.pub/ for an example.
• "c2s" doesn't cover the whole API. As I said above, only one section of the doc is called "Client-to-Server Interactions", and it doesn't cover the read-only side of the API.
• "c2s" is insider jargon. c2s isn't a common term for RESTful APIs. It really isn't a common term at all; there are only a few protocol suites, like XMPP, that refer to the "c2s" and "s2s" part.

I think it's fine if others use "c2s" when talking about the API, or especially about section 6 of the ActivityPub spec. It's not going to cause any harm. But the Social Web Community Group task force on implementing the API is called the "ActivityPub API" task force. I think that's a good idea – it emphasizes the API. I intent to use this name and framing for the foreseeable future.

Speaking of the quality of Apple's Private Cloud Compute model…

🫥

Discordはもともとクローズドなので、開かれたコミュニティ志向でやってるプロジェクトで採用するのはどうかって話ではあったかも。

コミュニティをDiscordからMatrixへ段階的に移行しています。メンテナーとコントリビューターはすでにMatrixに移っているため、今後はMatrixのほうが返答が早くなります。Discordはしばらく継続しますが、Matrixがメインの場となりました。

詳細とMatrixルームの一覧はこちら：https://github.com/fedify-dev/fedify/discussions/573（英文）

저희 커뮤니티를 Discord에서 Matrix로 조금씩 이전하고 있습니다. 메인테이너와 기여자들은 이미 Matrix로 옮긴 상태라, 앞으로는 Matrix 쪽이 응답이 더 빠를 거예요. Discord는 당분간 유지되지만, Matrix가 이제 메인 거점입니다.

자세한 내용과 Matrix 룸 목록은 여기서 확인하세요: https://github.com/fedify-dev/fedify/discussions/573.

We're gradually moving our community from Discord to Matrix. The maintainers and contributors are already there, so you'll get faster responses on Matrix going forward. Discord will stay up for a while, but Matrix is now our primary home.

For the full details and the list of Matrix rooms, see: https://github.com/fedify-dev/fedify/discussions/573.

What if Mastodon API Enhancement Proposals so that we won’t have 5+ different ways to change your password on platforms implementing MastoAPI?

@FredPraca 언젠가 韓國(한국)에 꼭 놀러오세요! 😀

@FredPraca 炸醬麵(짜장면)은 韓國式(한국식) 中華料理(중화요리)라서, 韓國(한국) 밖에서는 찾기 어려울 거예요. 😅

산라탕 먹고 싶다

부담없이 예약없이 들어가서 산라탕만 먹고 나올 수 있는 중국집이 있으면 좋겠어

오늘 저녁은 뭘 먹을까?

@jannem That's a fair point, and I think you may be right that a life sentence is harder to argue against on legal or moral grounds than a death sentence would be. The “this punishment is inhumane” argument essentially disappears.

My remaining concern is less about the courts and more about the presidential pardon. In South Korea, the president can unilaterally pardon anyone, and historically this power has been used as a political card rather than a matter of justice. Chun Doo-hwan's pardon wasn't really about whether his sentence was too harsh—it was a political calculation ahead of an election. So I worry that no matter how legally solid the sentence is, a future president could still undo it for reasons that have nothing to do with whether the punishment was proportionate.

That said, I'll admit this is more of a general anxiety about the pardon system than a specific prediction. Maybe the political cost of pardoning someone convicted of insurrection would be too high for any president to seriously consider. I hope so.

Today, 443 days after declaring martial law on December 3, 2024, former President Yoon Suk Yeol was sentenced to life in prison for leading an insurrection. The court found that his martial law decree, the deployment of troops to blockade the National Assembly, and the attempt to detain political figures constituted an act of insurrection against the constitutional order.

https://www.koreatimes.co.kr/southkorea/politics/20260219/ex-president-yoon-suk-yeol-sentenced-to-life-for-leading-insurrection

Many Koreans had hoped for the death penalty—the prosecution had asked for it, and the charge of leading an insurrection only allows three possible sentences: death, life with labor, or life without labor. The court chose life.

I have complicated feelings about this. As someone who believes the death penalty should be abolished, I shouldn't want it imposed on anyone, and in principle I don't—not even on Yoon. But there's a practical dilemma that's hard to ignore. South Korea has a precedent here: Chun Doo-hwan, who led the 1980 military coup and the Gwangju massacre, was sentenced to death at his first trial, reduced to life on appeal, and then pardoned by President Kim Young-sam. He walked free. If the starting point is already life in prison rather than death, it's even easier for an appeals court to reduce the sentence further, and for some future president to pardon him down the road.

So the discomfort isn't really about wanting Yoon to die. It's about the gap between what the sentence says and what actually happens in practice. And that points to a deeper problem: the presidential pardon power. As long as a sitting president can unilaterally pardon anyone—including someone convicted of trying to overthrow the very constitutional order the presidency is supposed to protect—no sentence feels truly final. I'd rather see the death penalty abolished and the pardon power curtailed, so that life in prison actually means life in prison.

법원이 내란 우두머리 혐의로 재판에 넘겨진 윤석열 전 대통령에게 무기징역을 선고했습니다. 김용현 전 장관에게는 징역 30년을 선고했습니다. 2024년 12월3일 비상계엄이 선포된 지 444일 만입니다.

[속보] 법원, 윤석열에 무기징역 선고…“비상계엄으로 ...

@cheeaun Oh, I didn't realize Hollo's quote didn't work on Mastodon… Here's the context: https://hackers.pub/@2chanhaeng/019c6d4e-ca99-7482-8663-8f3cb0d7cb9c.

Fedidevs, any ideas?

Edit: Here's the context: https://hackers.pub/@2chanhaeng/019c6d4e-ca99-7482-8663-8f3cb0d7cb9c.

I want to try making a highly autonomous fediverse bot, just for fun.

@pbzweihander 참새 이어서 해주세요…!

OK, I bought fedi.blue because I can, and I have no plans to use it for anything specific. Well, at least, I want to build an app that is compatible with both the fediverse (AP Protocol) and Bluesky (AT Protocol) ecosystem at the same time. So... if you have any ideas or suggestions, feel free to let me know! Sincerely, I want to waste money no more for domains that I won't use, so if you have any good ideas, please, please, PLEASE share them with me. You can find me at @chomu.dev on Bluesky and @2chanhaeng on Hackers' Pub. Or, you can also leave an issue in the repository. Thanks!

The fediverse is trans. Trans as in non binary. Trans as in transition. Trans as in transitional.

The fediverse is anti-capitalist. The fediverse is anarchist praxis. The fediverse is not a protocol. The fediverse caries an ideology of communal care and mutual aid for our fellow humans. The fediverse should never be neutral on ideology. The tools we are building provide infrastructure for communication but they also shape that communication.

i feel like i've probably asked this before but has anyone written a fancy command line man page viewer to replace `man`?

(not emacs or vim)

All documents published by the Ideographic Research Group (IRG) are now available on the Unicode web site, and can be easily and efficiently found through the new search bar provided on the IRG homepage.

🔗 https://www.unicode.org/irg/

This long-awaited search feature is very convenient, and so useful to find what you're interested in, and even more (ah, the wonderful power of serendipity!)...

#Unicode #IRG #IdeographicResearchGroup #CJK #Ideographs #Unihan

@FredPraca 제 이름의 마지막 글자는 「히」가 아니라 「희」입니다. 😀