Add datatype drafts

drafts/entity.md

@@ -0,0 +1,98 @@
+# A marketplace protocol optimized for localized trade of basic needs
+
+Same structure for asks (queries) and bids (stores, offers)
+
+## Usecases
+
+* transport (rides, deliveries)
+* accommodations
+* store with permanent location
+* store with single dynamic location
+* store with routes (multiple schedules and locations)
+
+
+## Core entity
+
+* identity public key
+* version (see changes below)
+* location
+
+### Location
+
+* polygon (city boundary) or point/sphere (e.g. entrance, pick-up spot)
+* origin only (e.g. store) or origin/target pair (e.g. rideshare)
+* categories (entrance, delivery radius, drop-off point...)
+
+
+## Optional core information
+
+### Times
+
+* schedules (opening hours) and one-offs (weekly market)
+* ranges and point/sphere ("pick up around")
+* negations ("but not between", "but not on")
+* categories (store opening hours, transport time window, accomm lease time, reservation deadline ...)
+
+
+### Product
+
+* uuid (in the domain of the entity identity key)
+* rdf schemas
+* should be loosely defined so that entry can be "groceries" and price ranges
+* extrapolate price to citing price on reference products against a price oracle, (but still instantiate)
+* each article can be stated in both spot and range in multiple currencies
+
+
+### Contact:
+
+* URN (email, msisdn, im...)
+
+
+## Auxiliary information
+
+Client itself chooses and assembles providers / indexers.
+
+* Entity description
+* Linked resources (website, social media...)
+* Municipality data (e.g. street address)
+* Ratings
+* Trust graphs
+* Payment providers
+
+
+## Datatypes
+
+### Point/sphere
+ 
+* optional progressive distance weighting formula, e.g. prefer items closer to the point (linear, curves...) or equally anywhere within sphere 
+
+
+
+## Changes
+
+* Version number increments for every change, no matter frequency
+
+
+### Mutability
+
+* Delta can contain only changes (add, delete)
+
+
+### Overides
+
+* time overrides, like "open now"
+* availability overrides, like "sold out"
+* price overrides, like "everything 50% off"
+
+
+### Pubsub
+
+* rapidly changing data
+* entity that is moving around (taxi)
+* prices that rapidly change (auctions)
+
+
+## vocabulary:
+
+* how does a vocabulary of "bare necessities" look like? (wood, maize, chicken, coal, single bed, car seat)
+* should not require map through language hub (english)

drafts/location.md

@@ -0,0 +1,52 @@
+# Location filter
+
+
+Using DHT, geopositional ranges could be used as a prefix to scope indexes and route queries.
+
+
+Earth circumference is around 40000 km. 
+
+Divided into 256 units, each unit would span around 150 km, which would constitute a feasible full-day roundtrip with motorized transport.
+
+Further divided into 16 units, each unit would span about 10km, which would constitute a feasible full-day roundtrip on foot (which is the reality of mobility for most people in the world).
+
+Further divided into 64 units, each unit would span around 150 metres, which is a couple of minutes' walk, or the equivalent of "what exists where I am right now," i.e. the smallest resolution needed in practical terms.
+
+In practice, the units would be defined by degrees, conventionally starting at 0N 0E.
+
+
+## Location filter base representation
+
+The above allows us to express the location scope in a series of three bit fields,
+
+- layer 1: bit 0-255: units of ~150 km
+- layer 2: bit 256-269: units of ~10km
+- layer 3: bit 270-333: units of ~0.15km
+
+Thus, the filter can be represented within 42 bytes per axis, or 84 bytes total.
+
+
+
+### Indexer scopes
+
+Indexers will declare the geopositional scope of their relevance.
+
+This would most likely be defined in layer 1 only. If an indexer only defines a single bit in layer 1, the protocol could advise that layer 2 is inspected for better granularity. And again the same with layer 2 and layer 3.
+
+
+### Ask and bid scopes
+
+A store would define its origin in coordinates, from which a location filter bit field would be compiled. The scope should always be defined in terms layer 3.
+
+When the ask or bid is announced on the network, the forwarders and indexers can make a simple bitwise comparison to determine whether it matches its scope, and/or choose where to forward it to. This will localize the gossip and limit network congestion.
+
+
+## Filter optimizations
+
+The filter could optionally be shortened by omitting the layer(s) that dont carry information (e.g. scope is only defined in terms of layer 1).
+
+
+The network could maintain consensus on e.g. the max scope limit any indexer may provide, and/or whether the scopes must be contiguous. 
+If the max limit was 1 unit in layer 1, then the layer one could be represented by a single byte only, whose numeric value defines the single relevant sector.
+
+Similarily, if scopes must be contiguous, only two numeric values would be needed; one to define the offset and one to define the number of units.

readlist.bibtex

@@ -141,3 +141,9 @@
 	url = "https://matheo.uliege.be/bitstream/2268.2/11657/12/thesis.pdf",
 	urldate = "2022-02-26",
 }
+
+@MISC{
+    author = "Wolfgang Nejdl and Boris Wolf and Changtao Qu and Stefan Decker and Michael Sintek Ambjörn Naeve and Mikael Nilsson and Matthias Palmer and Tore Risch",
+    title = "EDUTELLA: A P2P Networking Infrastructure Based on RDF",
+    year = "2001"
+}