Upend

Ʌ: Projects

UpEnd

Essential

  • alternative approach to filesystems
  • file storage as database; database as file storage
  • fs ⇋ db ⟹ allmighty library
  • ahierarchical // polyhierarcal approach…

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)

Use-Cases

Summary

🚧🚧🚧 TRANSLATE 🚧🚧🚧

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
    • struktura filesystemu samotna je taky key a value: FILE_shaiusdhuijhngsoyuhsdf BELONGS_TO_DIRECTORY shaoidsuhjaoijoiasjdioj
    • (kazdej key/value 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 s E/A/V tripletama, 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

(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!
  • 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/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!

Learn Datalog Today! 🌐

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 ?