ActivityPub - plan implementacji

Postanowiłem jednak zrobić kawałek ActivityPub w Devlogu. Potem może następny i następny, ale powoli i bez pośpiechu, w dodatku traktując AP jako ramówkę, a nie specyfikację protokołu.

Niedawno przypomniałem sobie ponownie o ActivityPub, którym interesowałem się już w okolicach 2018 roku, a to w kontekście pojawiającej się często potrzeby zapisania sobie (i u siebie) czegoś większego niż tweet, a mniejszego niż pełnowymiarowy post w blogu, do czego w dodatku istnieje choćby podstawowy klient na telefon. Oczywiście szybko okazało się, że różowo nie jest, a wręcz spec to jest jakiś zbiór niedopowiedzeń, przez co nie da się dobrze zrobić najważniejszego, a więc rozproszenia i współdziałania instancji. Sytuacja ogólnie jest niewesoła w tym ActivityPubie, ale jak sobie przemyślałem sprawę, to do tego co jest mi potrzebne się nada.

Co będzie miał AP w Devlogu

• outbox do zbierania od klienta aktywności których ja jestem autorem, jednak w przypadku żądań pobrania zawartości będzie zwracał pusty zbiór
• głuchy inbox, bo musi być, ale będzie działał jako zlew (komunikacja bez efektu z odpowiedzią OK)
• OAuth2, żeby klient mógł się autoryzować
• meta informacje pod /.well-known (webfinger z danymi użytkownika i nodeinfo z danymi instancji)

Jak widać, nie mam zamiaru robić żadnej federalizacji, ani tym bardziej implementować żadnych funkcji sieci społecznościowej, więc większość przykładowego lub bibliotecznego kodu nie będzie mi w ogóle potrzebna, jak również nie mam żadnego powodu żeby się przejmować niedoskonałościami specyfikacji ActivityPub.

Tyle na początek. Trudno mi powiedzieć, czy będę implementował coś więcej - jak zazwyczaj pewnie wyniknie to w trakcie użytkowania. Na tę chwilę nie mam takiej potrzeby, utworzoną zawartość i tak będę udostępniał ręcznie, a naprawdę nie widzę potrzeby porzucania tej czy innej platformy społecznościowej.