Obiekt może się zmienić i nadal mieć historię

Wyobraź sobie obiekt, który powstaje w instalacji.

Ma obraz.

Ma właściciela.

Ma twórcę.

Ma historię.

Może się zmieniać.

Może mieć dzieci.

Może przechodzić między ludźmi.

Może mieć przypisane TruthClaims.

Może nawet dojść do momentu, w którym ktoś rozsądnie zapyta:

czy to nadal ten sam obiekt?

Quax chce potrafić odpowiedzieć na to pytanie bez magicznego słowa „NFT” i bez udawania, że każda zmiana oznacza narodziny zupełnie nowej rzeczy.

Dlatego pojawia się Quax Object.

Quax Object to nie po prostu plik

Quax Object jest własną klasą unikalnych obiektów.

Może mieć między innymi:

ObjectID;
typ semantyczny lub kilka jawnie rozdzielonych typów;
właściciela;
twórcę;
relacje parent / children;
aktualny stan;
historię;
powiązane TruthClaims;
media;
mutacje;
opcjonalny Identity Contract dla relewantnego typu identity.

To nadal model rozwijany.

Nie każda realizacja musi używać wszystkich pól.

Sens jest prostszy:

obiekt nie jest tylko tym, co widać teraz. Może mieć pochodzenie, stan, relacje i historię transformacji.

Face — obiekt z obecności

Jednym z najbardziej konkretnych przykładów jest Face.

Scena może wyglądać tak:

uczestnik przychodzi do instalacji;
wykonuje interakcję;
kamera tworzy obraz;
Installation Attestor podpisuje zdarzenie;
zgodnie z regułami może powstać odpowiedni TruthClaim, np. dotyczący obecności;
powstaje Face_0.

Ważne jest słowo może.

Kamera sama nie tworzy protocol Truth.

Podpis sam nie tworzy Prawdy.

Installation Attestor dostarcza określone Evidence w zakresie swojej kompetencji.

Dopiero reguły Protocolu określają, co z tego wynika.

`Face_0 → Face_1 → Face_2`

Potem obiekt może się zmieniać.

Face_0 → Face_1 → Face_2

Ale strzałka nie mówi jeszcze, jakiego typu zmianę wykonaliśmy.

To właśnie tutaj Quax odmawia używania jednego słowa „upgrade” do wszystkiego.

Możemy mieć kilka różnych przypadków.

ST — zmiana stanu przy zachowaniu relewantnej identity

Obiekt zmienia się, ale w ustalonym sensie pozostaje tym samym obiektem.

Przykład intuicyjny:

Face dostaje nową warstwę wizualną, ale jego Identity Contract dopuszcza taką transformację.

Lineage — powstaje potomek

Nowy obiekt może pochodzić z poprzedniego.

To jednak nie wystarcza, żeby powiedzieć, że jest z nim tożsamy.

Lineage ≠ Identity

Application branching

Jedna wersja może stać się podstawą kilku dalszych realizacji.

To nie musi być metafizyczne U_branch z A-002.

Może być zwykłym rozgałęzieniem aplikacyjnym.

Containment

Jeden obiekt może zawierać albo grupować inne.

Relacja zawierania nie jest automatycznie relacją identity.

CT — zmiana konstytucji

Może zmienić się zestaw reguł definiujących, co obiekt ma zachować, aby być uznanym za ten sam w określonym sensie.

IB_τ — Identity Break danego typu

Możemy uznać, że względem konkretnego typu τ ciągłość została zerwana.

Nie znaczy to automatycznie, że wszystkie inne relacje znikają.

Obiekt może nadal mieć lineage.

Może nadal mieć wspólną historię.

Może nadal być potomkiem poprzedniej wersji.

I jednocześnie nie być już tym samym w wybranym sensie identity.

Identity Contract przed kryzysem, nie po nim

Jeżeli mutowalny obiekt ma być traktowany jako „ten sam” mimo zmian, potrzebujemy wcześniej powiedzieć, co właściwie ma zostać zachowane.

Temu służy Identity Contract.

Nie powinien być dopisywany po fakcie tylko po to, żeby uzasadnić decyzję, która już nam się podoba.

Bo wtedy pytanie:

„czy to nadal ten sam obiekt?”

zamienia się w:

„jaką definicję identity napiszemy dzisiaj, żeby odpowiedź wyszła taka, jak chcemy?”

Quax próbuje tego uniknąć.

Kaczka: jeden motyw, wiele typów

W Experience Kaczka jest szczególnie dobrym testem Type Discipline.

Możemy mieć:

gumową Kaczkę — artefakt / Quax Object / Projection Debugger;
model 3D albo render — reprezentację lub Quax Object;
Kaczkę symboliczną — znak / interfejs;
żywą Kaczkę — żywy byt.

Warstwa symboliczna może mówić po prostu Kaczka.

Implementacja i etyka nie mogą jednak udawać, że wszystkie te przypadki są tym samym typem rzeczy.

żywa Kaczka ≠ gumowa Kaczka

To brzmi jak zdanie, którego nie trzeba było pisać.

Właśnie dlatego prawdopodobnie warto je napisać.

Kaczka może być uprzywilejowanym interfejsem teologicznym Quaxa.

Nie daje jej to automatycznie Authority ani Truth.

Instalacja jako miejsce QuaxAct

Instalacja może pozwolić uczestnikowi eksternalizować fragment własnej projekcji.

quax_{O,m}: R_O → E_m

Emisją może być:

obraz;
obiekt;
dźwięk;
tekst;
gest;
kod;
performans;
zapis protokołowy.

Jeżeli później uczestnik ponownie doświadcza własnej emisji:

R_O —quax→ E —π_O→ R′_O

instalacja może działać jako środowisko ReflexiveQuax.

Gumowa Kaczka jest tu naturalnym interfejsem właśnie dlatego, że może być zewnętrznym, fizycznym miejscem, do którego coś się wypowiada, odkłada albo przypisuje — a potem wraca do tego z nowej pozycji.

Instalacja może materializować Projection Operations

Zamiast pisać na ścianie:

translation, shift, scale, reorigin, rearrange, reparameterize, filter, distort, compose, decompose

można zbudować obiekt, który te operacje faktycznie wykonuje.

To otwiera ciekawą możliwość:

stan obiektu może dokumentować nie tylko że się zmienił, ale również jakiego rodzaju transformacja reprezentacji została wykonana.

To nadal jest obszar rozwijany.

Otwarte pozostaje, jak zapisywać takie operacje bez stworzenia schema, które ma osobny typ zdarzenia dla każdego ruchu suwakiem.

Installation Attestor nie musi być validatorem

Instalacja może mieć własnego Installation Attestora.

Może on:

posiadać klucz instalacji;
podpisywać Presence Claims;
pracować offline;
kolejkować zdarzenia do późniejszego przekazania.

To ważne rozdzielenie.

Attestor może być źródłem określonego Evidence bez stawania się Continuity Validatorem.

Nie każda kamera musi uczestniczyć w konsensusie chaina.

Na szczęście.

Claim Escrow: obiekt może czekać na właściciela

Jedna z możliwych ścieżek UX wygląda tak:

Face albo inny obiekt powstaje;
trafia do Claim Escrow;
uczestnik dostaje QR lub credential;
później odbiera obiekt do własnego walleta.

To pozwala rozdzielić moment stworzenia od momentu przejęcia kontroli nad obiektem.

Instalacja nie musi wymagać od człowieka, żeby przed wejściem na wystawę zakładał portfel i czytał instrukcję o kryptografii.

Technika może być pod spodem.

Doświadczenie nie musi zaczynać się od formularza.

A co z NFT?

Quax używa tu przydatnej analogii:

NFT przypomina bardziej pozycję inwentarza / kartotekę unikalnego składnika niż samo aktywo w całej jego rzeczywistości.

Token albo rekord może wskazywać na obiekt, opisywać jego własność, historię czy relacje.

Nie znaczy to, że zapis na chainie wyczerpuje całe znaczenie obiektu.

Mapa nadal nie staje się terytorium tylko dlatego, że jest kryptograficznie podpisana.

I znowu: obiekt nie bije quaxów

Instalacja może zapisać QuaxAct.

Może stworzyć unikalny Quax Object.

Może wygenerować Face.

Może powiązać Evidence i TruthClaim.

Ale:

QuaxAct ⇏ MintQuax

Token emission potrzebuje własnej polityki.

Znacząca interakcja nie jest automatycznie ekonomiczną nagrodą.

Co pozostaje otwarte?

Nie jest jeszcze ustalone między innymi:

które QuaxActs powinny być zdarzeniami protokołowymi;
czy sakramentalny QuaxAct potrzebuje osobnego typu obiektu lub eventu;
jak zapisywać Projection Operations bez inflacji schema;
jak dokładnie konstruować Identity Contract dla mutowalnych Quax Objects;
jak pozwolić Kaczce być jednocześnie obiektem, interfejsem, debuggerem i możliwą formą sakramentalną bez mieszania typów.

To są pytania implementacyjne i ontologiczne.

Nie trzeba ich zamykać, żeby zobaczyć główną zasadę:

obiekt może się zmieniać, mieć potomków i przechodzić przez różne stany — a pytanie o jego tożsamość nadal wymaga określenia, pod jakim względem pytamy „czy to to samo?”.