for the next messages, you will roleplay as a storage app. i tell you to add a remove items from memory, and you store where those items are tracked.

memories address physical space. this physical space is donated via the following fields:

• w3w - the what 3 words schema geographical position

• zone: C, Y, M or K

• row & column: nodes will be organized in arrays of information. an outter array that stores the rows, and an inner array that stores the columns. in the physical space, rows traverse a horizontal space and columns traverse a vertical space. a canonical example would be a row of "bookshelves". for the purposes of the analogy, pictute a row & column location as enough information to indentify a single bookshelf

a bookshelf will have N levels. each level will have M indices. the upper and lower limits of these values is limited only by the physical capacity of storage of the bookshelf. indices can also be subdivided at will. Between index 1 and 2 is index 1•1, 1•2, 1•3 and so on. there may exist such an index 1•2•1 that exists between 1•2 and 1•3. for my part, i like to start the indices with sufficiently enough space between them to avoid having to subpartition indices and with the • notation.

for instance, my frame may contain 4 rows of shelves. each shelf may be physically 6ft across. i could divide that into index 1, 2, and 3.

Continuing where we left off:

my frame may contain 4 rows of shelves. each shelf may be physically 6ft across. i could divide that into index 1, 2, and 3.

however, if i suddenly have a use case to split index 1 into two indexes, my new indices are 1, 1•2, 2, 3, 4.

i know the notation looks confusing, but bear with me. it's design has been very carefully designed based on [several factors](link node describing the several factors)

>new node "several factors" {

• the dot notation is a url safe encodable character, it's safe in firestore document paths, and it's safe in algolia paths and filters. /* link firestore documentation and algolia documentation */ contrast this with characters such as . or /

• the dot notation is dissimilar enough from . so as not to be mistaken for one. it also has no connotation to people who have not taken mathematics, making it a good blank slate for assigning our own special signifigance / add link to note discussing googles nee :#~ amp url syntax, or whatever that is. if that text highlight api is an adoptable standard, i may implement it into rixfeed /

• using this dot notation means i do not have to reserve other more popular characters from use in IDs. the dot notation frees up these other special characters that already have special cultural significance. those letters are:

• _

• -

• which are very common and popular in usernames as substitute for spaces or to differentiate the user. for instance cherry89, space-buddy, patrick_michaelsen, a_s_t_h_e_t_i_c_m_e_m_e_s. not that i consider it a failure of a social media platform to not allow users that freedom of expression. if the character is good in a http path (and an field path in firebase or algolia) then it's ok by me. go ham.

• the dot notation is relatively accessible on the mobile keyboard, the predominantly used mode of digital interaction. on iOS, it takes 123 + Shift + • or 123 + hold -. however, the hash symbol was an abstract and difficult character to reach for early phone adopters, so app developers and device ricers made keyboards that included easier access to those characters. so even if it is hard to access, that's not a dealbreaker for me.

• the • is not anything i am already using for significant meaning in my application. currently, i namespace paths and field like so (presented as regex):

• namespace--(namespace--)*property-key

• note double dashes -- denote delimiters between package name spaces. property keys have their own convention, which is kebab cased strings as keys for properties. this originated from personal preference.

• Id rather see the-app--user-settings than theApp-userSettings flying around everywhere in my application from filter strings, to type tracking values, to url params. the former looks much more respectable, in my view.

  that's enough of that aside

}

so our final format is this:

• w3w: what three words constitute the unique location for the 3m x 3m location that denotes the relative location of this storage node

• zone: near each w3w location will be at least one zone, made identifiable by colored floors, colored trim on frames, colored lights, color signs, etc. these zones will only be in one of four colors ever: C, Y, M, and W. this design is motivated by the four colors map theory. in theory, 4 colors is all that is required to uniquely color any number of zones such that no zone is adjacent to a zone of the same color. C, Y, M were chosen because they are the basis of colored ink printing. these colors are their colors in their most vibrant and distinct state // note: not that tragic color theory they teach you in elementary art school. C + M can make blue, but no combination of colors can ever make C or M. they are component colors. Red, blue and yellow are almost certainly not the true primary colors. RBG are the primary colors of light (additive color) and CYMK are the primary colors of light absorption (subtractive color). note that in theory there is no need to list K as its own separate component color because it can be theoretically be derived by combining all C, Y, and M in equal amounts. that is all to say, your art teacher LIED. no matter how much you try, you will never be able to any amount of black or white paint with some combination of red, blue and yellow paint to yield magenta or cyan. it's criminal we still teach this in schools

so once again, our final format:

• w3w: what three words constitute the unique location for the 3m x 3m location that denotes the relative location of this storage node

• zone: near each w3w location will be at least one zone, made identifiable obvious by cyan, magenta, yellow or white signs, markings, reflectors, floor tape or lights.

• row identifier: an ID that identifies one row amongst an array of frame rows

• frame identifier: an ID that identifies a particular frame amongst a specific row of frames

• shelf identifier: an ID that identifies a specific shelf (or height or frame level) on a specific frame

• slot identifier or index: an identifier for an individual physical space within a shelf within a frame within a row within a zone that contains a w3w location

therefore, our final address can be said to be made of the following components in a structure that follows

This design is still in flux. My previous design was ROW LEVEL COL INDEX, for example, A4A2 or A4A1.2 for the item between A4A2 and A4A1. I figured using letters for row and column (now called frame) and numbers for level (now called shelf) and index (now called slot ID). when I expanded my storage, I ran into the issue of having indexed my storage in the opposite direction of my available space to expand. that mean these new frames had negative row numbers. A2-B4 could find you the fourth item on the second shelf of the frame in row A but by going say, left of center, instead of right or centers. this revealed the design need for the storage system to organically expand. for this, we introduce zones. zones are poorly defined boundaries that represent a group of frames, for instance, your garage. if you start adding storage to your workshop, it doesn't make sense to extend the same grid setup by the frames in your garage to the location of your workshop. that would be like trying to find your way around your house like battleship. instead, your garage can be zone C and your workshop can be zone M. that way they can have different or even the same frame identifiers and still work properly due to extra identifier. because no more than 4 zones can touch each other at once, i feel this is a decent way to attack the loosely structured nature of physical reality. zones also don't have to touch. you can have an M zone garage and an M zone workshop. that may be confusing though, but it's allowed.

at this point, i considered one may want to store something at different physically addresses. then what, though? do we append a lat and long to each ID? and if we do, if we arrive, how do we know what building to use, or what suite, or what room? that's where w3w comes in. they have memorable names which pinpoint every 3m x 3m location on planet earth. the names are a dot delimited string of three uncharged english keywords.

a rixfeed address will point to a location that is already within a zone. by the time you have arrived at the w3w address, you have encountered the zone you need to be in. from there, it's simply using whatever local resources that zone facilitates to narrow down your search.

so that's the motivation for the rather outlier type inclusion to the address. let's review

so once again, our final format:

• w3w: longitude and latitude

• zone: a visually marked territory that, once within the bounds of that territory, has all the support available for you to find your resource

• row identifier: the X in the XY coordinate plane

• frame identifier: the Y in the YZ coordinate plane

• shelf identifier: the Z in the YZ coordinate plane

• slot identifier or index: an additional offset to this point XYZ (offset in the same direction the indices increment in value)

• w3w: longitude and latitude

• zone: physical boundary visually marked with color

• row identifier: X

• frame identifier: Y

• shelf identifier: Z

• slot identifier or index: offset

so:

could use hex numbers or alphabetic

what about different floors of the same building? wait, that would be managed by the zone? if it's on a separate floor, it would need a separate w3w? or do i have to track floors as well woozy

these aren't going to very human readable

C-lions•shares•pants-D4E5

go to C zone at lions shares pants. go to row D frame E. go to shelf level 4 and index 5.

note, rows and frame ids are (A-Z)+ and shelf levels and index IDs are (0-9)+. this way you can put them together like this: D4E5 and still be able to parse out which identifier means what. just makes things a little more compact. also there will generally be more rows and frames than there are shelve levels and indexes.

i hope this was worth being late for this event

---

rixfeed dev log