387553;20200720101205;VGhlIHByb29mIG9mIHdvcmsgb2YgdGhpcyBtZXNzYWdlIHNob3VsZCBiZSAyMCBiaXRz;#oln
is an example message on the not yet created OLN network. I imagine it to work as follows:
- the message consists of a numeric nonce, a date+time field, a base64url encoded payload and a keyword separated by ;
- the message is first sha1 hashed and the binary prefix zeroes counted. the message is put in memory under the keyword in a hashtable with a value derived from the strength of the POW that will decrease over time
- to create space for new messages, the messages with the lowest POW can be removed from memory.
- the keyword is in this case a hashtag (do include the #!) but other possible options are pluscodes, URLs, usernames, public keys or hashes of other messages.
- you could establish signed messages in the payload.
- putting hashes of other messages here can enable threading of messages.
- you can put a hash in the payload to add more keywords to a message
- signed messages with a public key might also be used to encrypt messages as a response. these responses should use the hash of the message they are responding to as the keyword, or otherwise the public key of the original sender.
- identifiers like a public key or a nickname could be used to target specific users, but without any guarantee by the protocol that this will be read.
- with hierarchic keywords, it can be good to also send a version of the more generic/higher up variants in the keyword field, e.g. a bigger region in the case of pluscodes. It might be a good idea to chain keywords at the end to enable narrowing in on e.g. subjects per region.
The mode of transportation of these messages is in principle carrier-agnostic, but probably should include at least node to node active message pushing and retrieval on request of specific messages (which could be done by OLN messages themselves, e.g. with special keywords) and JS accessible endpoints that could be used for dynamic webapps. The basic idea for spreading the messages through the network should basically be semi-biased gossip, as in the messages go over the network with a preference for the specific purposes of a node and messages with a higher POW. messages with a low POW could be chosen to be only immediately passed along instead to enable chat purposes.
in my previous work, which you can find at https://github.com/p9c/pod I created a proof of work system with one algorithm but multiple targets to have multiple parallel block intervals operating at once. It occurs to me that higher proof miners could be submitting lower target shorter intervals - to change the checking - thing is though the check is expensive so idk. Anyway, point being that you could have several degrees of difficulty for different purposes like you suggest. Ah yes, and my algorithm uses mainly very large integer long division, which cannot be done faster than on a 64 bit CPU (intel, amd). So it also can function on lower spec devices with 32 bit dividers like ARM processors and GPUs.