# UpEnd

# 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
>   - 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](upend_notes_tmp.pdf)


> (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
- 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](https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies)

### Similar projects

[Perkeep](https://perkeep.org)

[greglook/vault](https://github.com/greglook/vault)

[greglook/blocks](https://github.com/greglook/blocks)

[greglook/merkledag-core](https://github.com/greglook/merkledag-core)

## Criticisms, filesystems

[Files, Formats and Byte Arrays](https://shalabh.com/programmable-systems/files-and-file-formats.html)

[Programátorova kritika chybějící struktury operačních systémů](https://blog.rfox.eu/cz/Programatorova_kritika_chybejici_struktury_operacnich_systemu.html)

## Highly adjacent projects!

[Learn Datalog Today!](http://www.learndatalogtoday.org/chapter/1)

# Information enters, is processed
![[mapping_language.png]]

# 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 ?