# s@ : 정적 사이트 기반 탈중앙 소셜 네트워킹 > Clean Markdown view of GeekNews topic #27452. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27452](https://news.hada.io/topic?id=27452) - GeekNews Markdown: [https://news.hada.io/topic/27452.md](https://news.hada.io/topic/27452.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-13T09:43:43+09:00 - Updated: 2026-03-13T09:43:43+09:00 - Original source: [satproto.org](http://satproto.org/) - Points: 9 - Comments: 1 ## Summary **정적 사이트 기반의 탈중앙 소셜 프로토콜인 `s@`는** 각 사용자가 자신의 웹사이트를 통해 데이터를 직접 소유하고 교류하는 구조를 제안합니다. 모든 게시물은 **암호화된 JSON 저장소**에 보관되며, 브라우저가 이를 복호화해 피드를 구성합니다. 중앙 서버 없이 도메인 간 직접 통신으로 작동해, 인플루언서 중심의 확산 대신 **도메인=신원**이라는 단순한 원칙 아래 개인 간 신뢰 기반의 네트워킹을 실험합니다. ## Topic Body - **정적 웹사이트를 이용한 탈중앙 소셜 네트워킹 프로토콜**로, 각 사용자가 자신의 데이터를 직접 소유하고 관리하는 구조 - 모든 데이터는 **암호화된 JSON 저장소**에 보관되며, 브라우저 클라이언트가 피드를 집계하고 게시물을 발행 - **서버나 릴레이 없이** 친구 간 웹사이트와 브라우저 간 직접 통신으로 작동 - 사용자의 **도메인 이름이 곧 신원**이며, HTTPS/TLS를 통해 인증 - 단순한 구조로 **자기 주권형 소셜 네트워크**를 구현, 개인 간 신뢰 기반 교류에 초점 --- ### sAT Protocol 개요 - `s@`는 **정적 사이트 기반의 탈중앙 소셜 네트워킹 프로토콜**로, 각 사용자가 자신의 웹사이트에 데이터를 저장 - 모든 데이터는 **암호화된 JSON 파일** 형태로 저장되며, 브라우저 클라이언트가 이를 읽고 게시물 발행 및 피드 집계 수행 - **중앙 서버나 릴레이 없이** 작동하며, 데이터는 사용자의 사이트에서 친구의 브라우저로 직접 이동 - **상호 팔로우 관계**가 있어야 게시물 교류가 가능하며, 인플루언서 중심 구조를 배제 - 프로토콜은 GitHub Pages 등 특정 호스팅 서비스에 종속되지 않음 ### 신원(Identity) - 사용자의 **도메인 이름이 신원** 역할을 수행 - HTTPS/TLS를 통해 도메인 소유자가 콘텐츠를 게시했음을 인증 ### 디스커버리(Discovery) - `https://{domain}/satellite/profile.json` 경로에서 **프로토콜 버전과 공개키**를 제공 ```json { "satproto_version": "0.1.0", "public_key": "<base64-encoded X25519 public key>" } ``` - 기본 경로 `/satellite/` 외에 다른 경로를 사용할 경우, `.well-known/satproto.json` 파일로 실제 저장소 위치 지정 가능 ### 암호화 모델(Encryption Model) - 모든 사용자 데이터는 **암호화된 JSON 저장소**에 저장되며, 사용자와 팔로워만 복호화 가능 - **X25519 키쌍**을 사용해 공개키를 `profile.json`에 게시하고, 개인키는 브라우저 `localStorage`에 저장 - 게시물 데이터는 **XChaCha20-Poly1305**로 암호화되며, 콘텐츠 키는 팔로워별로 `libsodium`의 `crypto_box_seal`로 암호화 - `keys/_self.json` 파일에는 사용자의 콘텐츠 키와 게시 비밀정보가 포함되어 있으며, 본인만 복호화 가능 #### 키 회전 및 언팔로우 - 언팔로우 시 새로운 콘텐츠 키를 생성하고 모든 게시물을 재암호화 - 남은 팔로워에 대해 새 키 봉투를 생성하고 `keys/_self.json` 갱신 - 언팔로우된 사용자는 더 이상 게시물을 복호화할 수 없음 #### 복호화 흐름 - 방문자가 친구의 사이트를 방문하면, 자신의 개인키로 `keys/{follower-domain}.json`을 복호화하여 콘텐츠 키 획득 - 이후 `posts/index.json`과 개별 게시물(`posts/{id}.json.enc`)을 가져와 복호화 ### 데이터 구조(Data Schema) - 각 게시물은 개별적으로 암호화된 파일로 저장되며, `posts/index.json`은 게시물 ID를 최신순으로 나열 - 게시물 객체 예시: ```json { "id": "20260309T141500Z-a1b2", "author": "alice.com", "created_at": "2026-03-09T14:15:00Z", "text": "Hello, decentralized world!", "reply_to": null, "reply_to_author": null } ``` - 게시물 ID는 ISO8601 UTC 타임스탬프와 4자리 랜덤 해시로 구성 ### 팔로우 목록(Follow List) - `https://{domain}/satellite/follows/index.json` 경로에 평문 JSON으로 저장 ```json { "follows": ["bob.example.com", "carol.example.com"] } ``` - 암호화되지 않으며, 키 봉투를 통해 팔로우 관계가 이미 노출됨 ### 피드 집계(Feed Aggregation) - 클라이언트는 팔로우 목록을 읽고 각 팔로워의 게시물을 복호화하여 **시간순 피드**를 구성 - 게시물은 `created_at` 기준 내림차순으로 정렬 ### 댓글(Reply) - 댓글은 `reply_to`와 `reply_to_author` 필드가 설정된 게시물 - **중첩 댓글은 지원하지 않으며**, 최상위 게시물에만 직접 댓글 가능 - 원 게시물을 볼 수 없는 경우(비팔로우 상태 등) 댓글은 표시되지 않음 ### 게시(Publishing) - 새 게시물 생성 → 콘텐츠 키로 암호화 → 정적 사이트에 업로드 → `posts/index.json` 갱신 - 업로드에는 GitHub Contents API 등 사용 가능 - 게시 비밀정보는 `keys/_self.json`에 암호화되어 저장 ### 정적 사이트 구조 예시 ``` {domain}/satellite/ profile.json # 공개키 및 프로필 posts/ index.json # 게시물 ID 목록 {id}.json.enc # 암호화된 게시물 follows/ index.json # 팔로우 목록 keys/ _self.json # 콘텐츠 키 및 자격정보 {domain}.json # 팔로워별 콘텐츠 키 ``` ### FAQ - “RSS + 암호화인가?” → 예 - “AT Protocol에서 파이어호스 없는 버전인가?” → 예 - “확장성 있는가?” → 아니오 (“우정도 확장되지 않는다”) - “s는 slow/shitty의 약자인가?” → 예 - “자가 호스팅 가능한가?” → 예, 단 **CORS 활성화 필요** ## Comments ### Comment 52940 - Author: neo - Created: 2026-03-13T09:43:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47344548) - 많은 **대안적 소셜·자체 호스팅 네트워크**들이 겪는 문제를 이 프로젝트도 겪는다고 느낌 암호화 중심 설계가 멋지긴 하지만, 새 기기로 바꾸면 친구 팔로우를 복구하기 어렵고, X25519 키쌍 같은 개념도 일반인은 이해하기 힘듦 나는 단순히 **아이디·비밀번호 기반**으로 서버가 암호화를 대신 처리하는 구조가 더 현실적이라 생각함 이런 접근이야말로 비기술적 사용자도 쓸 수 있는, 빅테크를 대체할 수 있는 방향이라 봄 - 나도 비슷한 생각을 함. 하지만 **중간자 없는 세상**을 원한다면, 결국 비기술 사용자들도 스스로 조금은 관리하는 문화적 변화가 필요하다고 느낌 - 초기 설정 후 개인키를 내보내서 비밀번호 관리자 등에 보관하면 됨. 직접 프로토콜을 구현할 게 아니라면 복잡하지 않음 다만 가족이나 친구에게는 내가 대신 세팅해줘야 할 수도 있음. 그래도 자기만의 웹사이트를 갖게 되면 꽤 좋아할 것 같음 - 글 하단 FAQ에 따르면 이건 **AT Protocol(BlueSky)** 의 일부 요소를 뺀 개념적 실험에 가까움 실제로는 정적 블로그를 BlueSky에 통합하는 아이디어로 볼 수 있음. BlueSky 아이덴티티를 활용하거나, 정적 사이트 생성기 플러그인으로 인증 정보를 자동으로 가져오는 식으로 개선 가능함 - 예전에 이메일을 소셜 네트워크 전송 계층으로 쓰는 아이디어를 시도했지만 실패했음 [관련 글](https://medium.com/@hliyan/email-re-skinned-as-a-social-network-c33b175f3a9e) 참고 - 빅테크를 대체하는 게 목표인지 모르겠음. 단지 **작은 커뮤니티**가 유용하게 쓸 수 있다면 그것만으로도 성공이라 생각함 - 브라우저의 **localStorage에 개인키를 저장**한다는 부분에서 놀람 브라우저 설정 초기화나 재설치 시 데이터가 날아가고, 백업도 어렵고, 악성코드 접근은 쉬움 결국 키를 잃으면 피드도 영영 사라져서 사용자들이 떠날 위험이 큼 - 동의함. “X25519 키쌍” 같은 용어를 아무렇지 않게 쓰는 걸 보면, 이 프로젝트는 대중적 확산보다는 **개념 실험**에 가깝다고 느낌 - “안전한 위치에 키 내보내기” 버튼 하나로 해결 가능하다고 생각함. `URL.createObjectURL(localStorage.getItem(...))` 같은 간단한 코드로 파일 저장 유도 가능함 - 완벽을 추구하다가 **‘충분히 괜찮은’ 해결책**을 놓치면 안 됨. 키 다운로드/업로드 기능만 추가해도 대부분 문제는 해결됨 물론 키 분실 시 접근 불가하지만, 2FA나 암호화폐 지갑 사용자들도 비슷한 책임을 감수하므로 완전히 불가능한 일은 아님 - `/satellite/` 경로 대신 `/.well-known/`을 쓰면 어떨지 제안함 [Well-known URI](https://en.wikipedia.org/wiki/Well-known_URI) 표준을 참고함 - “.poorly-known”이라며 농담으로 응답함 - AT Proto 초기에 루트 경로를 써서 **보안 취약점**이 생겼던 걸 떠올리며 걱정함 - `.well-known`은 호스트 전체용이라 스트림 단위에는 부적절하다고 주장함. 여러 디렉터리를 분리해두는 게 낫다고 봄 - `.well-known/` 제안은 진지하게 고려할 만하다고 생각함 이미 **IANA 등록 표준**으로 널리 쓰이고, 보안·발견용 파일들이 여기에 위치함 `/satellite/satproto.json` 대신 `/.well-known/satproto.json`에 두면 충돌도 피하고 프로토콜 엔드포인트임을 명확히 알릴 수 있음 - 하지만 `.well-known`은 호스트 단위라 계정별로 여러 디렉터리를 두고 싶을 때는 맞지 않다고 반론함 - 소셜 네트워크 프로토콜은 기술 자체를 위한 게 아니라 **사용자에게 직접적 이익**을 줘야 함 BitTorrent처럼 사람들이 단순히 ‘필요해서’ 참여하게 만들어야 네트워크 효과가 생김 데이터 관리와 공유 편의성에서 출발하는 접근이 현실적이라 생각함 - 내가 여러 **탈중앙 SNS**를 써보니, 결국 사람들은 도파민 자극이 없으면 방문하지 않음 Lemmy나 Pixelfed는 콘텐츠가 적어 “아무 일도 안 일어나는 곳”처럼 느껴졌음 Signal도 마찬가지로 단순 메시징용이라 ‘스크롤할 이유’가 없음 결국 **콘텐츠와 FOMO(놓칠까 두려움)** 가 있어야 지속적으로 방문함 - 그래도 좋은 프로토콜 설계는 중요함. 복잡하거나 미래 대비가 부족하면 아무리 좋은 아이디어도 금방 사라짐 - 진짜 **탈중앙화된 소셜·E2EE 메신저**를 만들려면 Discord처럼 각 서버가 실제로 독립적으로 호스팅되는 구조가 필요함 계정은 Nostr 같은 프로토콜로 관리하고, Yggdrasil Network 위에서 동작해 IPv4/6, DNS 의존도를 줄여야 함 HTTPS로 트래픽을 감싸고 NAT 우회를 자동화하면 누구나 서버를 운영할 수 있음 이런 구조가 되어야만 빅테크와 정부의 통제에서 벗어날 수 있음 - 하지만 기술만으로는 안 됨. **대중은 결국 마케팅 자본이 큰 플랫폼**으로 몰릴 것임 - 나는 BitTorrent, IPFS 같은 **캐시 기반 분산 네트워크** 접근이 더 낫다고 봄 서버가 사라져도 데이터가 엣지에 남고, 사용자 브라우저가 호스트 역할을 할 수도 있음 [ephemeral-p2p-project](https://gabe.durazo.us/tech/ephemeral-p2p-project/) 참고 - 이런 구조는 이미 [geogram.radio](https://geogram.radio)에서 실험 중임 각 기기가 서버로 동작하고, WebRTC로 완전 P2P 메시징을 구현함 인터넷이 없어도 **라디오 연결**로 데이터 교환 가능함 - 나는 Mikoto Platforms에서 비슷한 걸 만들고 있음. “Spaces”가 물리 노드 어디에나 존재할 수 있고, DM은 다중 노드를 거쳐 **E2EE 라우팅**됨 - 예전에 **FOAF**나 [Pingback](https://en.wikipedia.org/wiki/Pingback) 같은 완전 탈중앙 소셜 시도가 있었음 - 그 현대적 버전이 [Webmention](https://indieweb.org/Webmention)임 IndieWeb 위키가 이런 개인 웹 기반 소셜 기술을 탐구하기에 좋은 자료라 추천함 - 또 다른 예로 [XFN](https://en.wikipedia.org/wiki/XHTML_Friends_Network)도 잊지 말아야 함 - “sAT Protocol은 정적 사이트 기반의 탈중앙 소셜 네트워크”라는 설명을 읽으며 **눈썹이 점점 올라가는 그래프**를 그리고 싶었음 - 그래도 목표 범위가 좁은 만큼 합리적인 시스템이라 생각함 다만 **암호문이 공개적으로 열거 가능**해 양자컴퓨터 시대에는 위험할 수 있음 - 이건 **PGP + RSS** 조합과 유사함. 각 피드를 암호화해 개인만 복호화 가능하게 함 소규모 네트워크에는 적합하지만, 키 배포·회전 문제로 대규모 확장은 어려움 - “데이터베이스를 전송해 클라이언트가 정적 사이트를 빌드한다”는 개념으로 이해함 - “Key Rotation (Unfollow)” 부분은 ASCII 아트로 농담처럼 표현함 - 사용자 입장에서 이게 **무엇을 하는 서비스인지**부터 설명이 필요하다고 느낌 포크, 경로, JSON, 암호화 같은 기술 용어만 가득해서 실제 사용 시나리오가 안 보임 - 그래도 기술에 관심 있는 친구들이 꽤 있어서, **‘편집증적 보안 취향’** 을 가진 이들과 함께 실험해볼 생각임 Mastodon이나 Signal로는 충족되지 않는 영역이라, 이걸로 실험해볼 가치가 있음 - 이런 **탈중앙 네트워크 실험**을 보면 정말 흥미로움 비록 구조적으로 문제 많더라도 새로운 조합을 배우는 게 즐거움 다만 팔로우/언팔로우 시 전체 사이트를 다시 암호화·재빌드해야 하는 건 너무 번거로움 또, 팔로우하지 않으면 댓글이 안 보이는 구조는 **확장성**을 크게 제한함 그래도 RSS·ActivityPub·정적 사이트의 혼합이라는 점이 매력적임 정적 사이트로 **동적 친구 목록 접근 제어**를 구현하려는 시도는 모순적이지만 흥미로움 결국 사랑과 증오가 동시에 느껴지는 구조임. 그래도 이런 시도는 반갑고 고마움