Does this count for SD’s as well? If so, it wouldn’t be possible to use forward-referencing SD chains, where the next SD is posted with as identifier the hash of the previous SD. When trying to GET the entire chain one would get disconnected after trying to GET the non-existing SD after the last one.
That would be quite a pity, since we need forward referencing if we want to create truly decentralized linked-lists for decentralised discussion threads and such.
At the moment it will only be immutable data, SD is a slightly different mechanism and needs to be able to be free of this rule for the time being.
Thanks for the fast reply! So eventually it will be forbidden to GET non-existing SD’s?
I feel it will be settable whether these are allowed to be searched as some for sure will resist search (by returning dummy / random data every attempt). Things like login or session packets will likely follow this patter. So range based search protection.
@Seneca, SD’s can be updated, so link lists are easy without worrying about referencing non-existent ones. When you add one, simply update the null forward link on the previous ones to point to it and set null as pointer to next.
Can’t do that if the previous one isn’t yours. 
Ah, I see
Could blogs and the like use a multi owned SD then the blog APP can do the linking yet the poster still owns the SD as well. But of course that is app specific.
The other choice is that the APP “buys one SD in advance”, then the poster fills the previously bought one on the end of the chain ( or the poster’s post is copied into it to keep things atomic ) and the APP then buys another to link as the last in the chain. And it is then waiting to be filled later on.
The bought in advance SD can have its ownership transferred to the poster.
BUT of course if the posters own the SDs and they form a link list then what happens if the owner of one of those SDs decides to re purpose the SD and thus the chain is broken.
Maybe you would be better off with a system that uses SDs to point to the content and link those SDs which remain under the ownership of the APP. Each SD holds many pointers (and its hash to detect modification of content in the linked to content/SD) And link these pointer SDs together to form you link list of sorts.
Did that make sense?