digital-garden-anabasis/pages/UpEnd.md

UpEnd

Essential

• alternativni pristup k filesystemu
• file storage jakozto database; database jakozto file storage
• fs ⇋ db ⟹ allmighty library
• ahierarchickej // polyhierarchicky pristup...

Cut word lines Cut music lines Smash the control images Smash the control machine Burn the books Kill the priests Kill! Kill! Kill!

• William S. Burroughs - The Soft Machine (1961)

Summary

#czech

v podstate moje idea je :

Base structure

• databaze kde mas dva druhy objektu: data, a meta
  • (jedinej rozdil je, ze data actually odkazujou hashem na nejakej file, a meta neodkazujou nikam, jenom slouzej jako "anchor")
• a ke kazdymu objektu muzes mit arbitrarni keys a values
  • kazdy takovy key/value tvori jeden E/A/V triplet (see Entity Attribute Value model (Wikipedia)):
    • Entity = objekt (neconeco.mp3, resp. jeho hash)
    • Attribute = klic (year)
    • Value = hodnota klice (2020)
  • struktura filesystemu samotna je taky E/A/V triplet: FILE_shaiusdhuijhngsoyuhsdf BELONGS_TO_DIRECTORY shaoidsuhjaoijoiasjdioj
  • (kazdej E/A/V je taky objekt na kterej se da odkazovat, kdyby sis chtel anotovat anotace)

Schemas

• objekty maj kategorie, ktery znamenaj ze se muzes spolehnout ze objekt co je otagovanej "radio" ma: cas pridani, slozku, heaviness, etc.; co je otagovanej "public" ma: "projekt", "filetype", "rok", etc.
  • to je taky E/A/V triplet: Entita je ten objekt, Attribut je neco jako IS_A a Value je odkaz na kategorii (ktera je taky objekt slozeny z E/A/V tripletu - znacici co musi objekt splnovat)

Input

• pridavas soubory bud pres web rovnou do databaze, nebo syncthingoidne do filetree, a pak zarazujes

Output

• output je bud ten, ze je ven exposly jakysi APIcko, ktery ti dava jenom pristup do jedny z moznejch hierarchii, a s tim pracuje treba radio, nebo photo uploader, nebo OCRko
  • nebo ten, ze to proste pouzivas misto file browseru, ale kdykoli mas moznost se vratit zpatky na baseline filesystem kdyz najdes, co hledas

Geekmiscellanea

extremne zmateny notes z prubehu konceptualizace (pravdepodobne useless pro kohokoli jinyho)

(clarification - neni to teda jenom key/value, zjistil jsem ze se tomu rika entity/attribute/value, kdy ten key/value je jenom ta posledni dvojice, a "entity" je nejakej abstraktni anchor ke kterymu se pojej ruzny key/values; moje pointa je, ze entity nemusi bejt enom IDcko na ktery vazes, ale i primo data, ktery muzou existovat tim padem na vic mistech / jako vic filu zaroven (nebo taky zadny), a i ty samotny vztahy mezi entitama, cimz ti vznika moznost i nejak znackovat co vlastne o tech datech rikas)

Goals

• democratic user interface model a la Syncthing
• Content-Addressability
• K/V metadata store
• schemas / constraints on metadata
  • (auto-admin?)
• Links between objects
  • 1-way = Tags
  • 2-way = Relations
  • 3-way = ???
• 1st order tags
• 1st order links (?)
• kompozice souboru
  • skrz schemata! (sub-objekty pojici se k jedne ci vice entitam)
• Modes
  • R/O only
  • Hybrid
  • Full
• FS revisions / metadata only backups
• staging area, queues...

Resources // Inspiration

Whole systems

Design docs

❗https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies

Similar projects

❗ Perkeep

Greglook

greglook/vault

greglook/blocks

greglook/merkledag-core

Criticisms, filesystems

Files, Formats and Byte Arrays

❗ Programátorova kritika chybějící struktury operačních systémů

Highly adjacent projects!

Datalog

v podstate identicky E/A/V model

Learn Datalog Today!

BeOS / HaikuOS

https://www.howtogeek.com/696193/what-was-beos-and-why-did-people-love-it/

Idea s filesystemem jakozto databazi s metadaty:

https://www.haiku-os.org/docs/userguide/en/workshop-filetypes+attributes.html

Information enters, is processed

!

Random (and outdated) points

• content-addressability
• hidden structure within filetypes
• breaking apart from a hirearchy
• key/value store protocol // backend
• VFS compat layer
• config keys as files
• FS as a rich API
• syncthing model, sidecar files
• S3 API ?