ActivityPub/페디버스에서 유니코드 사용자명을 허용해야 하는 이유와, 표준(ActivityPub/ActivityStreams) 관점 및 흔한 반론들에 대한 답변을 다룬 글.
지금은 이미 미래다. 어디서든 유니코드를 써도 괜찮다.
현대의 인터넷 서비스가 가끔 “영어권(Anglosphere) 밖에도 세상이 있다”는 사실을 잊어버리는 것처럼 보이는 게 내겐 참 이상하다. 어떤 사람들은 뻔뻔하게도 외국어를 쓴다! 그리고 그 언어들 중 일부는 글자에 악센트도 붙는다!! 더 나쁜 건, 어떤 언어들은 영어 알파벳을 아예 쓰지 않는다!!!
10년 전, 나는 GitHub가 프로젝트 이름에 일부 ASCII 문자만 지원한다는 사실에 짜증이 났었다. 여러분의 저장소가 “ഹലോ വേൾ드”라고 불리지 못할 기술적 이유는 없다.
비슷하게, ActivityPub에서 가장 큰 서비스인 Mastodon이 유니코드 사용자명을 허용하지 않고, 바꾸려는 시도에도 저항해온 점이 나는 답답하다.
그래서 나는 작은 ActivityPub 서버를 만들어 @你好@i18n.viii.fi라는 Actor가 콘텐츠를 발행하도록 했다. 데모 계정일 뿐이지만, 동작한다!
어떤 ActivityPub 클라이언트는 이를 팔로우하고 메시지를 받는 게 가능하다고 보고한다. 다른 것들—예를 들어 Mastodon—은 아예 아무것도 보지 못한다. 어떤 서비스가 동작하는지 보려면 Mastodon에서의 답글을 확인해보라. 또 페디버스에서 그 계정의 게시물 일부를 확인할 수도 있다.
ActivityPub 명세는 이렇게 말한다:
연합(federated) 네트워크에서 국제적인 사용자 기반을 구축하는 것은 중요하다. 국제화(Internationalization)
사용자명이 어떤 언어로 쓰일 수 있는지 제한하는 내용은 명세에서 찾지 못했다. 다만 여기저기 단서가 몇 개 흩어져 있다.
사용자의 @ 이름은 preferredUsername로 정의되며, 이는 다음과 같다:
Actor를 지칭하는 데 사용할 수 있는 짧은 사용자명으로, 유일성이 보장되지는 않는다. 4.1 Actor objects
여기에는 어떤 문자 체계(script)를 포함할 수 있는지에 대한 언급이 없다. 하지만 뒤쪽에서 명세는 이렇게 말한다:
name,preferredUsername,summary같은 자연어 값을 담는 속성은 ActivityStreams에 정의된 자연어 지원(natural language support)을 사용한다. 4. Actors
즉, 선호 사용자명(preferred username)은 여러 문자 체계로도 작성될 수 있음을 전제한다. 이는 기본값이 A–Z0–9로 제한될 필요가 없다는 뜻이다.
또한 ActivityStreams 명세는 언어 매핑(language mapping)을 다룬다.
마지막으로, ActivityPub 명세에는 이름에서 라틴 문자가 아닌 텍스트를 사용하는 예시도 있다.
따라서 나는 사용자명이 다양한 비(非)라틴 문자 체계로 작성되는 것이 허용된다고 본다.
나 같은 “유니코드 어디에나(Unicode Everywhere)” 열성주의자에게는 보통 몇 가지 반론이 따라온다. 논쟁을 미리 차단해보고자 한다.
그래서 뭐? ASCII에도 비슷하게 생긴 문자가 많다. 대문자 I가 소문자 l로 바뀌는 걸 대부분은 못 알아챌 거라고 나는 생각한다(반대도 마찬가지). r과 n이 자간(kerning) 때문에 m처럼 보이는 문제도 잘 알려져 있다. 혼합 언어 homograph가 더 위험한가? 나는 그렇지 않다고 본다.
그러면 뭐? 내 언어를 타이핑할 수 없는 사람에게 검색되지 않는 것이 버그가 아니라 기능일 수도 있다. 어쨌든 클라이언트는 사용자가 다른 사람을 검색하게 하거나, 이름을 복사/붙여넣기 하게 할 수 있다.
입력된 텍스트를 어떻게 렌더링할지는 클라이언트가 결정할 문제다. 기묘한 유니코드 조합이 만드는 “문제”는 이미 잘 알려져 있다. 이는 어려운 컴퓨터 과학 문제가 아니다.
이에 대한 증거는 없다. 하지만 자기 이름을 입력하려고 키보드를 전환해야 한다면 꽤 짜증나지 않겠는가? 어쨌든 왜 내가 @😉 같은 사용자명을 가질 수 없다는 말인가?
ActivityPub 소프트웨어를 만든다면, 이름을 ASCII에 쉽게 끼워 맞추기 어려운 수십억 명의 사람을 생각해보라.
여러분의 소프트웨어가 @你好@i18n.viii.fi 및 그 게시물을 볼 수 있다면, 내게 알려달라.
이 글이 마음에 들었나? 저자를 후원해달라.
Harald Eilertsen (Hubzilla)
연결은 되네요, 적어도. 멘션도 되려나요?
L'égrégore André ꕭꕬ (mastodon.social)
“사람들이 자기 문자 체계로 사용자명을 원하긴 하나?”에 대한 답을 공식적으로 하자면:
네. 네, 원합니다.
훌륭한 작업이고 널리 퍼지길 바랍니다!
Tirifto :korektu_min: (jam.xwx.moe)
맞아요! 영어가 소프트웨어 개발에서 높은 지위를 가지는 건 사실이지만, 그게 사용자 측에서 어떤 편애로 이어져서는 절대 안 됩니다. 국제 사용자명 지원의 기술적 측면에서 당신이 다루지 않은 문제가 있을지 단정할 정도의 통찰은 없지만, 커스텀 이모지도 똑같이 ASCII 취급을 받는다는 건 알고 있어요. 그럴 이유가 전혀 없는데도요.
#Mastodon 과 #Firefish 에서는 이모지 관련해서 다음 이슈가 열려 있습니다:
#Pleroma 는 기본적인 이모지 지원은 있지만 게시물 언어 지원이 없습니다. 추가하려는 PR이 2개 있는데, 중요성이 지나치게 과소평가되는 듯합니다:
관련 소프트웨어 전반에 이슈를 열고 상태를 추적하는 것도 좋은 생각일 수 있어요. 그리고 더 많은 사람들이 (적절한 채널에서!) 이 주제를 말하고 지지 의사를 표현하면 “맞아, 이건 할 가치가 있어”라는 신호가 되겠죠.
𐑝𐑧𐑜𐑭 𐑓𐑘𐑹𐑛 ✡️🇵🇸 (freeradical.zone)
네! 임의적인 #anglocentrism 때문에 너무 짜증나요!
Bonfire (indieweb.social)
좋은 지적. (웹핑거 요청을 URL 인코딩하는) 한 가지를 고쳐야 했지만, 이제 Bonfire에서 원격 액터로 동작합니다.
LonM (social.vivaldi.net)
homograph 공격 문제에 동의해요. 온라인에서 대화/로그인/결제를 할 때는 올바른 곳에 데이터를 보내는 게 중요하죠. 그때는 사실상 도메인만 보고 판단해야 하고, 링크를 클릭할 때 특히 정확해야 합니다.
하지만 소셜 미디어에서는 oIIy 대신 olly를 팔로우하면 최악의 경우가 뭔가요?
치명적 보안 이슈가 있다면, 계정 이름은 유니코드를 허용하되 도메인은 punycode로만 허용하는 건 합리적인 절충안처럼 보입니다(그런 이유로 mastodon 도메인 검증 같은 것이 있죠).
이모지 계정 이름은… 이모지는 정말 엉망이라 전부 싫지만, 뭐 알아서 하세요.
Mina (cathode.church)
cathode.church(Glitch-social)의 Tusky는 @你好@i18n.viii.fi 에 자동으로 답글을 달지 못하고, 검색으로도 찾지 못하네요.
RevK :verified_r: (toot.me.uk)
제가 뭔가 놓친 게 아니라면, char*를 받아서 UTF-8에 대해 isalpha를 할 수 있는 더 새로운 ctype.h가 없는 게 아쉽네요. 비슷하게 (매번 직접 만들게 되는) 다음 문자 함수 같은 것도 필요하고요.
제가 수십 년 전부터 존재하던 범용 utf8.h 같은 걸 놓친 걸까요?!?!
하지만 ctype.h 만큼 가벼운 건 없을 것 같네요, 아쉽게도.
개인적으로는 0x80 이상은 모두 식별자 문자로 취급해도 대체로 만족할 것 같습니다.
Evan Prodromou (cosocial.ca)
이 노력에 100% 지지합니다. 당신이 겪는 문제는 ActivityPub이 아니라 Webfinger에 있습니다. 우리는 AP x WF의 공식 명세를 작업 중인데, i18n 관련해서 당신의 도움을 받고 싶어요:
Renée Burton (infosec.exchange)
슬프게도 우리는 아직 있어야 할 곳에 있지 않죠… 제가 보낸 Zoom 초대는 여전히 “Ren<무작위 쓰레기>e의 zoom 미팅에 참가하세요”라고 나와요. é 정도면 꽤 직관적일 텐데 말이죠.
William B Peckham (techhub.social)
로컬라이즈된 영어권 애플리케이션이나 DB 용도로는 원래 ASCII 같은 걸 쓰는 데 문제 없습니다. 하지만 일반적이거나, 국제적으로, 또는 전 세계적으로 쓰는 것이라면, 거의 모든 언어로 엉터리 번역을 생성할 수 있을 정도의 시대에 이보다 못한 걸 쓸 변명은 없다고 봅니다! 누구든 자신에게 낯선 언어로 코딩/스크립팅하도록 강요할 이유가 없어요. 2024년입니다. 국제적 해법이 있는데요!
Mike Macgirvin 🖥️ (fediversity.site)
우리는 UTF-8 사용자명을 지원하지만 10년째 기능 토글 뒤에 숨겨두고 있어요. 주된 이유는 해당 키보드가 없으면 누군가를 멘션하기 어렵고, 복사/붙여넣기 할 이전 사례를 찾기도 쉽지 않기 때문입니다.
arcayr (gts.rascals.net)
gotosocial 0.13.2 + elk 0.10.3에서는 프로필이 보이고 팔로우도 됩니다. 글에 있는 프로필 링크도 잘 동작해요.
cass, the Fae (fedi.cassfae.page)
hi, hi
최신 GoToSocial은 계정을 볼 수 있고, 백필(backfill) 부족만 아니면 게시물도 볼 수 있을 것 같아요.
Thomas Arildsen (fosstodon.org)
iOS의 Ice Cubes Mastodon 클라이언트에서는 사용자명을 탭하면 아래 JSON 응답만 나와요:
json{"subject":"acct:%E4%BD%A0%E5%A5%BD@i18n.viii.fi","links":[{"rel":"self","type":"application\/activity+json","href":"https:\/\/i18n.viii.fi\/%E4%BD%A0%E5%A5%BD"}]}
VelteropⓐⓊ🪂🇪🇺🇳🇱🇬🇧🇩🇪 (mastodon.online)
대체로 동의합니다. 다만 과학에서는 homograph가 문제를 일으키긴 해요. 예를 들어 β-carotene은 존재하지 않는 ß-carotene과 같지 않죠. (후자는 독일어 eszett(ß) 리가처인데, β를 뜻하려고 과학 문헌에서 종종 등장합니다. 사람 눈에는 큰 차이가 아니지만, 기계 가독성엔 큰 문제죠.)
Adam Kieliński (tech.lgbt)
성(姓) 중간에 네모(□)가 들어가던 일을 너무 많이 겪어서, 서구권의 공식 문서에 실명을 쓰는 게 꺼려졌습니다. 그래서 대신 “Kielinski”라는 가짜 이름으로 활동해요.
Adam Sjøgren (illuminant.asjo.org)
제가 직접 만든 ActivityPub 서버 Illuminant는 팔로우를 성공했고 follow Accept도 잘 받았습니다. 다만 다음 메시지가 떴어요:
2024-02-18 11:19:56 ÷ not notifying Fetch Activites as user has no outbox
그래서 @你好@i18n.viii.fi 의 최근 게시물을 가져오지 못했습니다.
Klaus Alexander Seistrup (magnetic-ink.dk)
toot을 통한 Pleroma에서는 이렇게 나옵니다:
» toot follow '@你好@i18n.viii.fi'
Error: Account not found
Tim Ward ⭐🇪🇺🔶 #FBPE (c.im)
“이건 어려운 컴퓨터 과학 문제가 아니다.”
😂
수십 년 동안 케임브리지 컴퓨터 과학 시험에 이런 문제가 있었죠: “숙련된 프로그래머조차도 왜 문자 코드 때문에 종종 어려움을 겪는지 설명하라.”
문제를 처음 썼을 때는 5트랙 종이테이프의 이스케이프 시퀀스 같은 답이 기대됐을 겁니다.
제가 시험을 봤을 때는, ASCII와 EBCDIC 사이에서 코드가 이식 가능한지(문자 중간에 구멍이 있었던 거 기억하나요?) 같은 걸 답으로 기대했을 거고요.
요즘엔, 당신의 툿(toot)이 답이 되겠네요.
cristei (tech.lgbt)
죄송하지만, 라틴 알파벳 말고 다른 걸 생각하기 시작하면 텍스트는 꽤 어려워집니다. 기본적인 지원조차 부족한 주된 기술적 동기이기도 하고요.
Rua (chitter.xyz)
Tusky는 대신 JSON이 들어 있는 웹페이지를 열어버리네요. 끝내주네요.
scary male spectre (お眠り) (wavebird.party)
솔직히 접근성 때문에 이 아이디어에 찬성하지 않습니다. 모든 것이 페디버스 핸들 복사/붙여넣기를 지원하는 것도 아니고, 많은 커뮤니티가 사용자명에 최소한 일부 영숫자(alphanumeric)를 요구하는 데에는 이유가 있어요.
참고로 제가 “영어권”에 속해서 그러는 게 아니라, 악센트 있는 글자를 쓰는 언어의 원어민으로서 말하자면, 이건 파란 체크마크 이모지보다도 쓸모없고, 장점보다 문제만 더 늘립니다.
(그리고 라틴 문자를 “영어 알파벳”이라 부르는 건… ggwp, 멋진 자폭이네요)
Terence Eden (mastodon.social)
답글 감사합니다. “자폭”이라는 표현에 대해.
글에서 과장법(hyperbole)의 목적은, 어떤 주장의 터무니없음을 독자가 명백히 극단적이라고 느낄 정도로 과장해 전달하는 것입니다. 예를 들어 저는 느낌표를 여러 개 썼고, 그 앞에도 비슷한 성격의 문장들을 몇 개 배치했습니다.
그로써 독자가 제가 그 주장에 동의하지 않는다는 점을(글의 나머지 부분에서 설명하듯) 이해하길 바랐습니다.
그게 명확하지 않았다면 죄송합니다.
Jorin (soc.punktrash.club)
pleroma에 husky를 쓰고 있어요. 사용자명이 https://i18n.viii.fi/.well-known/webfinger 로의 링크로 파싱됩니다. 답글 창에서는 입력하면서도 나타나지 않았습니다.
Jon "The Nice Guy" Spriggs (toot.io)
@Tusky 에서 계정 링크를 클릭하면 webfinger URL로 이동합니다.
Tito Swineflu (sfba.social)
제가 접하는 결제 처리기나 예약 시스템의 절반은 하이픈 들어간 이름조차 못 받는데, 당신은 너무 높은 걸 목표로 하는 것 같네요.
⚛️Revertron :straight: (zhub.link)
아니요, 제발 사용자명을 국제화하지 마세요.
피싱과 각종 취약점의 새로운 영역을 열게 될 겁니다.
federico (oldbytes.space)
homograph는 큰 보안 문제이고, 개발/디버깅/버그 리포트의 많은 프로토콜에서는 쉽게 출력 가능한 id가 필요합니다. ID를 QR 코드 같은 것으로 바꾸지 않는 한요…
Terence Eden (mastodon.social)
글에서도 말했듯이, ASCII에도 이미 H0M0GRAPH 문제가 있습니다.
그리고 당신은 모든 프로그래머가 자기 알파벳뿐 아니라 A–Z도 읽을 수 있다고 전제하고 있어요.
하지만 그렇지 않더라도, ID는 URL 인코딩될 수 있습니다.
glyn (fosstodon.org)
페디버스의 또 다른 i18n 제한은 해시태그가 매우 제한된 문자 집합만 허용한다는 점입니다.
mirabilos (toot.mirbsd.org)
흠.
클릭하면 webfinger URL로만 갑니다.
@ 형태로 검색하면 아무것도 안 나옵니다.
URL로 검색하면 이렇게 나와요:
timestamp="2024-02-26T17:53:27.591Z" func=server.glob..func1.Logger.func13.1 level=ERROR latency="59.686515ms" userAgent="…" method=GET statusCode=500 path=/api/v2/search clientIP=… errors="Error #01: Get: error searching by URI: byURI: error looking up https://i18n.viii.fi/%E4%BD%A0%E5%A5%BD as account: enrichAccount: error webfingering remote account 你好@i18n.viii.fi: fingerRemoteAccount: error extracting subject parts for @你好@i18n.viii.fi: couldn't match namestring @%E4%BD%A0%E5%A5%BD@i18n.viii.fi\n" requestID=xfdrssmd04001gtxd8yg msg="Internal Server Error: wrote 54B"
(이건 어제쯤의 GotoSocial main입니다)
개인적으로는 이 문제에 대해 복잡한 감정이 있습니다.
로컬파트(localpart)는 유니코드 코드포인트를 포함할 수 있어야 한다는 데 동의합니다. 다만 일부는 제외해야겠죠. 정확한 집합은 지금 바로는 모르겠지만, URL에서 허용되는 것들(서버와 / 뒤, 즉 path 컴포넌트에 들어갈 수 있는 문자) 정도면 괜찮을 것 같습니다.
하지만 도메인 파트는 ASCII에서 벗어나지 않는 쪽에 꽤 확고합니다. 즉 국제화가 필요하다면 유니코드 표기가 아니라 punycode(xn--something) 표기를 반드시 사용해야 합니다.
그래서 @☻@example.com에는 불만이 없지만, @foo@example.ею는 유효하지 않다고 봅니다. @foo@example.xn--e1a4c처럼 써야 하니까요. (클라이언트가 이걸 어떻게 처리할지는… IDN에서 늘 그렇듯 각자 알아서겠지만요… 하아)
Last Week in Fediverse – ep 56 – The Fediverse Report
[…] 페디버스를 국제화하자는 요구. 여기서 의미하는 건 Mastodon이 유니코드를 지원한다는 것 […]
모든 댓글은 검토 후 게시되며, 즉시 공개되지 않을 수 있습니다. 이메일 주소는 공개되지 않습니다.
댓글:
허용되는 HTML 요소 보기:
html<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <br> <cite> <code> <del datetime=""> <em> <i> <img src="" alt="" title="" srcset=""> <p> <pre> <q cite=""> <s> <strike> <strong>
이름(필수): 이메일(필수): 웹사이트(선택):
자신의 웹사이트에서 답글을 달려면, 이 글로 링크되는 게시물을 작성한 뒤, 그 페이지의 URL을 여기에 입력하라. WebMentions에 대해 더 알아보기.
글 URL/퍼머링크
검색어:
*(아카이브 목록 및 사이트 푸터 링크는 원문 페이지의 네비게이션 요소로, 본문 내용과 직접 관련이 없어 번역에서 생략합니다.)
ISSN 2753-1570 ⅯⅯⅩⅩⅥ