A. on the subject of “security” we have a #open policy of not trusting ANY client server security at all, so this should only be done #4opens as far as possible and having limited trust in #p2p security, even though we use this, because of the insecurity of the undelighting syteams it runs on, mostly old outdated phones, built as blobs by #dotcons this simple approach gets round much of the current thinking of technical “security” ie. the is almost non at a normal use level and little real security at the paranoid level as you will be talking to the normal level so there security will fail even if yours is solid. Good to keep this in mind 🙂
The #OMN is all about people messing around with each other’s data 😉 but yes we need good basic security, (sudo anonymous) accounts, public audit trails (#openprocess) everywhere. We will need digital hashes/cigs for media items etc. but the data itself just sloshes around and gets hacked at and added to. it’s a common, the rules are social based on trust flows, they are not mostly hard coded or encrypted. But we add a smidgen of hard-coding and decryption ONLY where it’s needed. So 90% trust flows, 5% social norms, 4% hardcoded, 1% encryption is my thinking.
A. Data has the value the instance itself is transitory, and yes the instance is needed and stores the data but if it vanishes it has little impact on the value (the data), we build this into the network.
Q. I am talking about the machines
A. We won’t the instance to stay up and be secure, BUT we build the network, so it keeps working when they are hacked and poised by bad actors.
Q. Yes, but that doesn’t mean we make things easy for bad actors
A. Yes, the code and instances have to be secure, but the network flows, and the data soup have to keep working when the individual instances are hacked and poisend, no security is fool prof and the #OMN is focused on building trust so is inherently more open to fools, we build with this in mind. We are building a #KISS semantic internet of data/flows. For example the idea of rollback as a core security model rather than more traditional hard (control) security is a good fit, due to the #4opens approach, the missing few days of data will (mostly) rollback into the instance so the cost of being hacked/trust failed is less of a block to being open and (social) trusting to bring in actors/sysadmins/moderates etc. On the tin, we are clear that our network is a trust based “lossy” network.
Where you can still run the #OMN as a hard control based secure network if you won’t BUT it will not scale to the social change/challenge if this second option is the only one, this is the current #geekproblem we need to work our way out of. The first path of trust based “lossy” is where the real horizontal “power” comes from.
Q. We sometimes need to think/talk about “security”.
A. I can only repeat I don’t have a solution to this, but I have a path to one, make the user facing “trust” based then from this, “trust” them to fix the next “problem” the #geekproblem of the hardcoded #feudalism of all our networks and code. Or in other words head in sand and pray someone else will fix it, am bussey 😉
On the #OMN projects maybe we need to list what needs to be secure: the account, the activity feed, the data credit might be more but can’t think of much else off the top of my head. And yes to secure the account the instance has to be secure, to secure the activity feed the flows need to be secure, to secure the credit the likely needs to be some hashing done on the media objects.
We likely end up back close to the place we started, but we come to this from a very different place, if that makes sense. This path we take matters.
