@7 blog

Ten wpis wynika głównie z mojego wcześniejszego marudzenia na frendica: To mnie uwiera: rozproszone tożsamości. tylko tym razem – dotyczy: jak można by rozwiązać problem dostarczycieli takich tożsamości.

Założenia – czyli co miałoby rozwiązywać toto.

  • Chciałbym mieć możliwość logowania się do usług związanych z fediverse za pomocą jednego loginu i hasła. Niezależnie czy byłby to serwer mastodona taki jak 101010.pl, czy instancja fredica taka jak sqeet.me czy jakaś inna pleroma – chciałbym móc używać w niej jednego i tego samego loginu do dostępu do usług, np: @seachdamh@rubiez.eu (https://rubiez.eu/@seachdamh).

  • Chciałbym móc uruchomić i być całkowitym właścicielem mojej usługi dostarczającej tożsamość. A więc nie być zmuszony z korzystania z jednego z kilku “monopolistów” i w ramach tylko tego co oni proponują. Chciałbym móc uruchomić sobie swojego VPSa, Rpi czy innego Pentima4 i móc w prosty sposób postawić wszystko co jest niezbędne do realizowania tej usługi.

  • Chciałbym, żeby ze strony usług korzystających z tej opcji (w rozumieniu innych serwerów mastodona, pleromy, itp) nie była wymagana absolutnie żadna konfiguracja, dopisywanie do jakiś list, ręczne uruchamianie czegokolwiek. Usługa ma być “samo opisująca” się i standaryzowana dla klienta.

  • Chciałbym używać i pisać na każdym z serwerów z wykorzystaniem mojej tożsamości.

  • Chciałbym, żeby serwer nie mógł wysłać żadnej informacji do fediverse podszywając się skutecznie pod moją tożsamość innym serwerom. Tak, nie ufam wam lewaki, prawaki i inne centrowi reakcjoniści.

  • Chciałbym, żeby relatywnie było trudne albo niemożliwe postawienie drugiej usługi która będzie podszywała się pod mój indentyfikator innym usługom.

Uch. Dużo i mało. Naturalnie na myśl przychodzi OAuth i delegowanie logowania, ale w tym wypadku chciałbym jeszcze, żeby można było w weryfikowalny sposób wysyłać wiadomości.

Bardzo z grubsza zarys pomysłu realizacji.

To jest raczej zbiór na razie luźnych pomysłów a nie kompletny, ostateczny zarys.

Tworzenie tożsamości.

Do tworzenia tożsamości musimy być potwierdzonymi właścicielami domeny, w ramach chcemy tworzyć tożsamości. Możemy to zrealizować przez odpowiednie wpisy z rekordach txt DNSów. W tej chwili widzę przynajmniej dwa takie rekordy:

  • fedi_identity.twoja.domena.tozasamosci.pl https://poddomena.domena.tozsamosci.pl/link/do/api – pozwalałaby dowolnej usłudze fediverse dowiedzieć się, że jeśli użyłem tożsamości @seachdamh@rubiez.eu to należy odpytać usługę dostępną pod adresem https://fediauth.rubiez.eu/api/v2/...

  • fedipubkey.twoja.domena.tozasamosci.pl klucz_publiczny.... – pozwala pobrać klucz publiczny, dzięki któremu posty wysłane z użyciem danego dostarczyciela tożsamości będą mogły być zweryfikowane jako pochodzące od niego i prawidłowe.

Podejście z użyciem domen pozwala nam stworzyć usługę, która będzie samoopisująca się i łatwa do odkrycia dla innych usług. Jak widać, zaczerpnąłem tutaj inspirację z rozwiązań używanych przez serwery poczty (spf, dkim, dmarc), które reguły właśnie w taki sposób przechowują. Do tego jest to mechanizm relatywnie elastyczny, pozwalający na łatwą rozbudowę o nowe reguły czy możliwości (jak np. deklarowanie grupy serwerów jako dostarczyciela tożsamości, np. w celach niezawodności działania usług).

Adekwatnie – oznacza to, że nie będąc właścicielami domeny rubiez.eu nie uruchomimy usługi dostarczania tożsamości w ramach przestrzeni nazw https://rubiez.eu/@uzytkownik

Łatwo mi tutaj też myśleć o rozszerzeniach protokołu o jakieś mechanizmy inne (dns blokchain, tożsamości na bazie identyfikatorów sieci i2p czy innych usług katalogowych), z tym, że przestrzenie nazw oparte na DNS powinny być możliwe do rozwiązania wyłącznie za pomocą dns.

Tworzenie wpisu / postu z wykorzystaniem “obcej” tożsamości dla serwera.

Jup, tu się robi trochę trudniej. Bo powiedzmy, jeśli chce mieć za pomocą tożsamości X stworzyć nowy element (wpis, toota, notke, dokument) na serwerze Y, oznacza to, że nie tylko ten serwer musi komunikować się z moim dostawcą tożsamości w trakcie logowania by mnie “wpuścić”, ale też każdy nowy element który tworzę za pomocą takiej “obcej” dla niego tożsamości wysłać do podpisania do mojej usługi i potem ten podpis zweryfikować za pomocą publicznego klucza dostępnego np. w rekordzie DNS.

Dopiero takiego artefakt powinien być wysyłany w świat.

  • jeśli serwer generowałby na własną rękę takie tożsamości – artefakt poszedłby ze złym/brakiem podpisu. Inne serwery za pomocą dostępnego klucza publicznego łatwo mogłybyby (i generalnie powinny mieć obowiązek) zweryfikować i wykryć taką sytuację.

  • Co zrobić ze zmianą klucza prywatnego? Wygaśnięciem? Właśnie, dobre pytanie. Być może cachowanie kluczy publicznych przez serwery byłoby jakąś odpowiedzią.

Usunięcie tożsamości. Niedostępność usługi. Itd...

Rozproszone tożsamości, znaczy też, że często gęsto usługi takie będą uruchamiane i wyłączane, będą więcej niż normalnie nękane przerwami w działaniu i podobnymi rzeczami.

Z artefaktami nie ma większego problemu. Raz, że klucz publiczny powinien być dostępny przez DNS, który z założenia jest dosyć stabilną usługą, dwa, że można też wymusić na serwerze z którego dane artefakty są wysyłanie obowiązek przechowywania też klucza publicznego, by w razie potrzeby można było też i z niego go pobrać. Choć myślę, że DNS powinien być metodą preferowaną i obligatoryjną w przypadku jej dostępności.

Z usunięciem np. domeny (a tym samym związanych z nią kluczy) jest większy problem – nagle znika nam dostępność kluczy publicznych, za pomocą można by zweryfikować stare posty. Ponownie – metodą jakąś jest lokalnie przechowywanie klucza przez serwer wysyłający artefakt.

Na koniec.

Pomysł oscyluje wokół dostawcy tożsamości ale łatwo mi sobie wyobrazić go również jako serwer innych danych, nad którymi chcemy mieć zupełną, całkowitą i pozostawiającą w naszych rękach – kontrolę. Bo nic nie stoi na przeszkodzie, żeby w ten sposób prezentować wizytówki, listy profilów czy innych danych związanych z danym identyfikatorem.

#mozenakiedys #todo #pomysly

Tak czytam sobie kolejny artykuł o konieczności modernizacji i transformacji firm (i nie tylko ich) w erę Dostępności Cyfrowej 4.0 czy jakkolwiek nie inaczej się to by nie nazywało.

I o ile część argumentów za tym stojących ma swoje ręce i nogi to notorycznie, niemal zawsze autorzy zapominają jednak o tym, że to nie zawsze są same plusy. Żeby było jasne. To też prawie zawsze nie są same minusy.

Jak zwykle, prawda leży gdzieś po środku.

Najmocniej chyba to się odnosi do małych firm. Im podmiot większy, tym lepiej dostosowana i atrakcyjniejsza oferta “usług” chmurowych w przeliczeniu na jednego pracownika lub jedno stanowisko.

Przeniesienie modelu płatności za oprogramowanie z licencyjnego / stanowiskowego na formę abonamentową

Niemal nowy, święty gral nowej ery. I faktycznie – oferuje wiele niezaprzeczalnych korzyści. * możliwość ciągłą aktualizację i posiadania najnowszego produktu, * łatwe dostosowanie w górę i w dół do potrzeb i ilości pracowników, * model płatności roczne, kwartalne, miesięczne pozwalające płacić tylko za “czas”, kiedy dany produkt jest potrzebny

Tyle, że to nie cała historia. Popatrzmy na produkt taki jak Office – chyba najpopularniejszy pakiet biurowy.

W małych firmach generalnie zatrudnienie nie waha się aż tak bardzo. Mniej więcej liczba pracowników jest stała. Podobnie jak fakt, że te narzędzia są potrzebne “zawsze”. Czyli zostaje argument ciągłych aktualizacji i posiadania zawsze najnowszej wersji który... też jest chybiony.

Bo zastanówmy się. Czy ja naprawdę w firmie potrzebuję najnowszego produktu? Czy robi mi wielkie znaczenie, czy mam tego Office 2019, czy 2016 czy nawet starszego? Tutaj narażę się panom od bezpieczeństwa ale.. nie. Narzędzie ma spełniać swoje potrzeby i funkcje i... tyle. To czy dokument napisałem w wersji pakietu 2016 czy 2019 nie ma większego znaczenia – dla większości małych i średnich firm nigdy zresztą nie będzie miało znaczenia, każde z tych narzędzi równie dobrze spełnia swoje zadania. A koszty? Koszty są zdecydowanie różne. Bo nawet jeśli abonament kosztuje połowę tego licencja na pakiet – to w kontekście 4,5 czy nawet więcej lat jego używania wychodzi to jednak nadal mniej korzystanie.

Przenoszenie infrastruktury na abonamentowe usługi.

Już nie wynajmujesz małego serwera dla obsługi poczty swoich 10 czy 15 pracowników, co miesiąc płacisz za konto na platformie Google czy Microsoft (czy adekwatnej). Tyle, że tam każde konto jest płacone “za pracownika”.

I jak popatrzysz na ceny – koszt konta dla pojedynczego pracownika jest prawie taki sam jak koszt małego serwera VPS na którym postawisz serwer poczty obsługujący wszystkich twoich pracowników. Jasne, niezaprzeczalnie dostaniesz: * więcej miejsca na poszczególnych kontach * łatwą do obsługi, skonfigurowania i administrowania usługę, którą każda, przeciętnie sprawna technicznie osoba ogarnie. * Elastyczne plany płatności, podobnie jak w oprogramowaniu.

Tyle, że kosztowo ponownie wychodzi to zdecydowanie drożej dla małej firmy niż własny serwer. Dochodzą też spraw związane z przechowywaniem, umiejscowieniem danych, dostępem do nich, możliwością łatwej migracji na inne rozwiązania.

Jesteś też całkowicie zależny od polityki bezpieczeństwa dużej firmy – co niekoniecznie musi być dobre. Przykładem jest taka poczta Microsoftu – firmy która na serwerach brzegowych swojej poczty blokuje całe podklasy IP tylko dlatego, że należą do dostarczycieli serwerów. Jeżeli twój klient wysyła ci pocztę z takiego IP – nigdy się nie dowiesz, że to próbował zrobić. Nie masz żadnej możliwości odblokować go na “swoim” serwerze – a on, generalnie – też nie ma żadnej możliwości, żeby sobie z tym poradzić. Gdybyś miał prawdziwy serwer a nie wykupioną usługę – po prostu wprowadziłbyś poprawkę w konfiguracji.

Podsumowując

Nie chcę odradzać “nowych rozwiązań”. Bo są nieraz wygodne, wydajne i mają całą masę plusów.

Jednak zanim zdecydujesz się na prowadzeniu firmy korzystając z usług abonamentowych a nie własnego oprogramowania dobrze by było, żebyś zastanowił się nad za i przeciw. Bo w usłudze koszty całościowe ogólnie są i będą wyższe. Podobnie jak możliwości personalizacji, konfiguracji i dostosowania do własnych potrzeb – najprawdopodobniej mniejsze. Tak, pominąłem dużo za, plusów – ale w sieci pełno jest artykułów, które to omawiają. Więc pozwoliłem sobie być tutaj subiektywnym malkontentem i skupić się na wadach.

Ostatnio mam więcej interakcji z oficjalnymi witrynami dostarczanymi nam przez jedyny i niepowtarzalny rząd polski. czyli mówiąc krótko – okolicami tego całego profilu zaufanego. Bo #epub, bo #ike, bo #e-deklaracje, bo narodowy spis powszechny – przez ostatni tydzień musiałem się logować w nich więcej razy niż chyba przez ostatni rok razem wzięty.

I tak jak zwróciło moją uwagę – dlaczego w tych wszystkich stronach na nagłówki i stopki przeznaczają tak ogromną część ekranu. Wygląda toto przez to topornie i zwyczajnie nieładnie. Rozumiem, że pewnie w takich witrynach mocniej, niż gdzie indziej wchodzą w grę wymagania dostępności, ale jakiś sprytniejszy grafik (aka disajner) nie mógłby się temu przyjrzeć i jakoś to przeorganizować? Mówię tutaj wyłącznie o szablonie strony, nie jakiś świecidełkach multimedialnych.

No więc, kolejny element składający się na układankę aplikacji korzystających z protokołu ActivePub. Tym razem jest to platforma do tworzenia bloga lub blogów (może być używana jako platforma dla wielu autorów, albo tak jak ja teraz robię – jako blog dla jednej osoby).

  • Na plus: Bardzo prosty, ascetyczny wręcz wygląd.
  • Na minus: instalacja (właściwie jej możliwości) wymagają jeszcze dopracowania. Schowanie jej za proxy Apacha gdy chciałem mieć to w podkatalogu głównej domeny zamiast w stworzonej specjalnie na te potrzeby poddomenie okazało się niemożliwie. Albo ja jestem taka łajza i w to nie umiem.
  • Na plus: prosta, przejrzysta konfiguracja samej aplikacji.
  • Na minus: kolejna tożsamość w świecie fediversum (wolałbym, żebym mógł publikować z wykorzystaniem już którejś z istniejących tożsamości, najlepiej np. frendica)
  • Na minus: funkcjonalny brak komentarzy, federowanie oznacza w gruncie rzeczy po prostu wysyłanie informacji do fedi o poście. Jednak nie tylko nie ma komentarzy z poziomu bloga, ale tym bardziej nie “zbiera” komentarzy z fedi (rozumianych jako odpowiedzi na wysłaną informację)

Mocno jeszcze niedokończone. To takie moje pierwsze wrażenia.