s@ : 정적 사이트 기반 탈중앙 소셜 네트워킹

(satproto.org)

3P by GN⁺ 4시간전 | ★ favorite | 댓글 1개

정적 웹사이트를 이용한 탈중앙 소셜 네트워킹 프로토콜로, 각 사용자가 자신의 데이터를 직접 소유하고 관리하는 구조
모든 데이터는 암호화된 JSON 저장소에 보관되며, 브라우저 클라이언트가 피드를 집계하고 게시물을 발행
서버나 릴레이 없이 친구 간 웹사이트와 브라우저 간 직접 통신으로 작동
사용자의 도메인 이름이 곧 신원이며, HTTPS/TLS를 통해 인증
단순한 구조로 자기 주권형 소셜 네트워크를 구현, 개인 간 신뢰 기반 교류에 초점

sAT Protocol 개요

s@는 정적 사이트 기반의 탈중앙 소셜 네트워킹 프로토콜로, 각 사용자가 자신의 웹사이트에 데이터를 저장
- 모든 데이터는 암호화된 JSON 파일 형태로 저장되며, 브라우저 클라이언트가 이를 읽고 게시물 발행 및 피드 집계 수행
- 중앙 서버나 릴레이 없이 작동하며, 데이터는 사용자의 사이트에서 친구의 브라우저로 직접 이동
상호 팔로우 관계가 있어야 게시물 교류가 가능하며, 인플루언서 중심 구조를 배제
프로토콜은 GitHub Pages 등 특정 호스팅 서비스에 종속되지 않음

신원(Identity)

사용자의 도메인 이름이 신원 역할을 수행
HTTPS/TLS를 통해 도메인 소유자가 콘텐츠를 게시했음을 인증

디스커버리(Discovery)

https://{domain}/satellite/profile.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를 최신순으로 나열

게시물 객체 예시:

{
  "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으로 저장
```
{ "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 활성화 필요

▲

GN⁺ 4시간전 [-]

Hacker News 의견들

많은 대안적 소셜·자체 호스팅 네트워크들이 겪는 문제를 이 프로젝트도 겪는다고 느낌
암호화 중심 설계가 멋지긴 하지만, 새 기기로 바꾸면 친구 팔로우를 복구하기 어렵고, X25519 키쌍 같은 개념도 일반인은 이해하기 힘듦
나는 단순히 아이디·비밀번호 기반으로 서버가 암호화를 대신 처리하는 구조가 더 현실적이라 생각함
이런 접근이야말로 비기술적 사용자도 쓸 수 있는, 빅테크를 대체할 수 있는 방향이라 봄
- 나도 비슷한 생각을 함. 하지만 중간자 없는 세상을 원한다면, 결국 비기술 사용자들도 스스로 조금은 관리하는 문화적 변화가 필요하다고 느낌
- 초기 설정 후 개인키를 내보내서 비밀번호 관리자 등에 보관하면 됨. 직접 프로토콜을 구현할 게 아니라면 복잡하지 않음
  다만 가족이나 친구에게는 내가 대신 세팅해줘야 할 수도 있음. 그래도 자기만의 웹사이트를 갖게 되면 꽤 좋아할 것 같음
- 글 하단 FAQ에 따르면 이건 AT Protocol(BlueSky) 의 일부 요소를 뺀 개념적 실험에 가까움
  실제로는 정적 블로그를 BlueSky에 통합하는 아이디어로 볼 수 있음.
  BlueSky 아이덴티티를 활용하거나, 정적 사이트 생성기 플러그인으로 인증 정보를 자동으로 가져오는 식으로 개선 가능함
- 예전에 이메일을 소셜 네트워크 전송 계층으로 쓰는 아이디어를 시도했지만 실패했음
  관련 글 참고
- 빅테크를 대체하는 게 목표인지 모르겠음. 단지 작은 커뮤니티가 유용하게 쓸 수 있다면 그것만으로도 성공이라 생각함
브라우저의 localStorage에 개인키를 저장한다는 부분에서 놀람
브라우저 설정 초기화나 재설치 시 데이터가 날아가고, 백업도 어렵고, 악성코드 접근은 쉬움
결국 키를 잃으면 피드도 영영 사라져서 사용자들이 떠날 위험이 큼
- 동의함. “X25519 키쌍” 같은 용어를 아무렇지 않게 쓰는 걸 보면, 이 프로젝트는 대중적 확산보다는 개념 실험에 가깝다고 느낌
- “안전한 위치에 키 내보내기” 버튼 하나로 해결 가능하다고 생각함. URL.createObjectURL(localStorage.getItem(...)) 같은 간단한 코드로 파일 저장 유도 가능함
- 완벽을 추구하다가 ‘충분히 괜찮은’ 해결책을 놓치면 안 됨. 키 다운로드/업로드 기능만 추가해도 대부분 문제는 해결됨
  물론 키 분실 시 접근 불가하지만, 2FA나 암호화폐 지갑 사용자들도 비슷한 책임을 감수하므로 완전히 불가능한 일은 아님
/satellite/ 경로 대신 /.well-known/을 쓰면 어떨지 제안함
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 참고
- 이런 구조는 이미 geogram.radio에서 실험 중임
  각 기기가 서버로 동작하고, WebRTC로 완전 P2P 메시징을 구현함
  인터넷이 없어도 라디오 연결로 데이터 교환 가능함
- 나는 Mikoto Platforms에서 비슷한 걸 만들고 있음. “Spaces”가 물리 노드 어디에나 존재할 수 있고, DM은 다중 노드를 거쳐 E2EE 라우팅됨
예전에 FOAF나 Pingback 같은 완전 탈중앙 소셜 시도가 있었음
- 그 현대적 버전이 Webmention임
  IndieWeb 위키가 이런 개인 웹 기반 소셜 기술을 탐구하기에 좋은 자료라 추천함
- 또 다른 예로 XFN도 잊지 말아야 함
“sAT Protocol은 정적 사이트 기반의 탈중앙 소셜 네트워크”라는 설명을 읽으며 눈썹이 점점 올라가는 그래프를 그리고 싶었음
- 그래도 목표 범위가 좁은 만큼 합리적인 시스템이라 생각함
  다만 암호문이 공개적으로 열거 가능해 양자컴퓨터 시대에는 위험할 수 있음
- 이건 PGP + RSS 조합과 유사함. 각 피드를 암호화해 개인만 복호화 가능하게 함
  소규모 네트워크에는 적합하지만, 키 배포·회전 문제로 대규모 확장은 어려움
- “데이터베이스를 전송해 클라이언트가 정적 사이트를 빌드한다”는 개념으로 이해함
- “Key Rotation (Unfollow)” 부분은 ASCII 아트로 농담처럼 표현함
사용자 입장에서 이게 무엇을 하는 서비스인지부터 설명이 필요하다고 느낌
포크, 경로, JSON, 암호화 같은 기술 용어만 가득해서 실제 사용 시나리오가 안 보임
- 그래도 기술에 관심 있는 친구들이 꽤 있어서, ‘편집증적 보안 취향’ 을 가진 이들과 함께 실험해볼 생각임
  Mastodon이나 Signal로는 충족되지 않는 영역이라, 이걸로 실험해볼 가치가 있음
이런 탈중앙 네트워크 실험을 보면 정말 흥미로움
비록 구조적으로 문제 많더라도 새로운 조합을 배우는 게 즐거움
다만 팔로우/언팔로우 시 전체 사이트를 다시 암호화·재빌드해야 하는 건 너무 번거로움
또, 팔로우하지 않으면 댓글이 안 보이는 구조는 확장성을 크게 제한함
그래도 RSS·ActivityPub·정적 사이트의 혼합이라는 점이 매력적임
정적 사이트로 동적 친구 목록 접근 제어를 구현하려는 시도는 모순적이지만 흥미로움
결국 사랑과 증오가 동시에 느껴지는 구조임. 그래도 이런 시도는 반갑고 고마움

답변달기