Search results

요즘 (https://github.com/cosmoslide/cosmoslide) 개발하면서 들고 있는 생각....


대부분의 액티비티펍 소프트웨어 인스턴스는 멀쩡하게 365일 24시간 동일한 위치에서 운영이 되고 있다고 가정이 된다. 내가 글을 올리면, 나를 팔로우 중인 모든 사람들의 inbox에 내가 글을 올렸다(Create(Note))는 Activity가 전달이 되는데, 각자가 운영되고 있는 서버 인스턴스가 멀쩡히 살아있다면.... 딱히 문제가 되지는 않는다.

문제는, 게시글을 작성하는 시점에 팔로워 중 누군가의 인스턴스가 죽어있을때도 있다는 점이다. 그런 경우를 대비해서 exponential backoff를 쓰든 아무튼 fallback 알고리즘이 동작하긴 하는데, 서버가 살아나면 당연히 전달이야 잘 되긴 한다. 그런데, Activity 전달이 실패하는 일이 잦으면 어떤 액티비티펍 소프트웨어를 쓰던간에 retry를 하기 위해서 계속해서 Queue에 쌓이고, 최종적으로는 Queue에 쌓인 것 때문에 적지 않은 오버헤드가 있을 것 같은데 모더레이터의 입장에선 어느 정도까지 감안할 수 있는가? 라는 생각이 문득 들었다.

사실 내가 왜 이런 글을 쓰고 있냐면, 위에서도 언급했다시피, 로컬호스트에서 실제로 서비스를 (맥북이 켜져있을때만) 서빙하고 있고 그걸 Tailscale로 연결해서 터널링을 하고 있다. 즉, 맥북을 켜놓고 있으면 Create(Note) Activity가 정상적으로 잘 전달되고, 맥북이 꺼져있으면 Activity 전달이 안되고 있다. 실제로, 이런 맥락에서 지금 테스트 중인 두 개의 인스턴스가 있다. 이런 실험적인 시도를 하면서 이래도 되는게 맞나 싶은 생각도 들고는 있다. 맥북을 켜놓으면, retry되고 있는 것도 다 consume되긴 하겠지만.... 찝찝하긴 찝찝하다.

개발하는 입장이라고 선해를 할 수는 있어도, 비뚤어진 관점에서 해석하면 누군가는 어뷰징의 관점으로 해석할 수 있는 가능성이 적지는 않다고 생각하고 있다. 이런 경우엔 모더레이터되는 분들한테, 내가 이런 tailscale 도메인으로 서빙하고 있다고 통지라도 하는게 나으려나... 아니면, 내가 구매해놓은 도메인을 tailscale 도메인으로 CNAME 걸어놓고 "이런 도메인으로 서비스 걸어놓을 예정이니까 이 도메인만은 제발 차단하지 말아주십쇼 헤헤" 라고 해야하나... 아예 서버를 만드는거다보니까 이런 고려사항이 생기는 것 같다.


근데, 한 편으로는 이런 생각이 든다. 물리적인 서버의 위치를 옮길 가능성이 많은 환경(예를 들면, 전시 상황)이면 어떡하지? ActivityPub이 사실은 분산된 웹 환경을 위해 나온 프로토콜이긴 하지만, 분산된 웹 환경이라는게 물리적으로 각자 다른 위치에 오랫동안 배치가 되어 있는 서버 뿐만이 아니라 위치가 자주 바뀔 수 있는 서버도 연합의 대상으로 포함이 될 수 있다면? 어떤 공상과학 영화(ex. 터미네이터4)들을 보면, 저항군이 독자적인 라디오 기지국 같은거 만들고 위치도 매번 다른 곳으로 옮기고 주파수를 매번 다르게 설정하면서 소식전달하는 모습을 볼 수 있는데, 액티비티펍도 어떻게 보면 그걸 고려한 설계도 포함될 수 있지 않나... 그런 생각도 든다..

1

2025-09-07 오늘의 작업한 내용 메모

https://github.com/cosmoslide/cosmoslide/pull/14

게시글 작성 기능까지는 안 갔지만, 연합우주 네트워크를 통해서 Create(Note), Announce(Note) 등의 액티비티가 들어왔을때 그것이 타임라인 화면에 노출되게 하는 기능을 작업했다. Actor 정보를 가져오는 과정에서 어떤 Actor는 lookup 하는 과정에서 Timeout 에러 뜨고, 어떤 Actor는 401 Unauthorized 뜨고, 어떤 Actor는 Person이 아니었어서 게시글 가져오는건 실패했는데... 이건 지속적인 개밥먹기를 꾸준히 해봐야 제대로 개선이 될 것 같음.

1

2025-09-03 오늘의 작업한 내용 메모

https://github.com/cosmoslide/cosmoslide/pull/13

  • 이전 버전까지는 Cosmoslide 의 모든 계정은 public이고 팔로우 버튼을 누르면 바로 팔로우가 되는 로직으로 구현이 되어 있었음.
    • 즉, Follow 액티비티를 받으면 액티비티를 보낸 액터의 inbox에다가 바로 Accept(Follow) 액티비티를 보내는 구성
  • 이번에 작업한 내용은 각각의 계정을 private으로 변환할 수 있고, private 계정에 팔로우 버튼을 눌렀을때 바로 팔로우가 되는게 아니라 팔로우 요청으로 처리되도록 하는 작업이었음
    • 즉, Follow 액티비티를 받으면, manuallyAcceptsFollowers 옵션이 false인 경우에만 Accept(Follow) 액티비티를 보냄
  • 팔로우 요청 관리하는 화면 바이브코딩으로 적당히 빠르게 만들고..... 팔로우 요청을 수락하거나, 팔로우 요청을 거절하는 액션 자체는 서버 측 비즈니스 로직에서 처리한다기 보다는 가능하면 Federation에서 처리하도록 했음.
    • 즉, 팔로우 요청 수락버튼을 누르면 Accept(Follow) 액티비티가 전송되고, 팔로우 요청 거절 버튼을 누르면 Reject(Follow) 액티비티가 전송되는 방식

로컬 환경에 있는 서로 다른 두 액터끼리는 잘 되는걸 확인했는데, 서로 다른 서버의 액터끼리 잘 되는지는 좀 더 테스트가 필요함.

이번 주말까지는 게시글 작성하고 원격 서버 타임라인에 노출되는 것까지 어떻게 되긴 할 듯.

2