Comment Re:Cool Idea, Bra (Score 1) 269
A better model would be random partial replication between servers.
Not sufficient. My on-ramp server could potentially edit my post before passing it on for replication. I'm not sure if this is solved by your later comment about putatively authoritative servers or if that one only applies between the replication servers? I don't know enough about the iApple model to judge this one here.
It's possible to verify the signature on the message using the public key in the profile for purposes of authentication (*NOT* authorization!) and non-repudiation purposes. You would require the intersection of two information vectors be compromised in order to alter someone's message - equivalent to controlling both the forward and reverse DNS entries for SMTP spoofing; presumably, you would not be subject to unsigned information there, the way the DNS system *without* DNSSEC fails to protect SMTP today.
It also requires a level of cooperation that's unlikely between competing players.
I already specifically noted that it's arranged as a mutual security game on the GloboCop model. This is the same model that was used during the cold war to prevent active warfare larger than brushfire wars. The math on it is rather complex to explain, but I could give you references to works by the Sante Fe Institute and the Brookings Institute. It's mathematically supportable.
This interferes with the "I want to be able to unsay stupid stuff"/"I want to be able to use the server while high or drunk and fix it later" feature
No it doesn't. If the protocol includes a "delete message X" command
Let me stop you right there. This would open the protocol to the "cancelbot" problem. It can't be allowed. What you can do instead is to implement "no_see_ums". You, or any exterior level of containing groups of subsets of the implied group "everybody" (but not "everybody" itself) can decide to "subscribe" to a set of of things in the category "I'd rather not see that". The top level is always unfiltered, and you can have "politeness" groups of "I'd rather you not see my drunken ramblings" on top of that. Polite people join the "politeness" group, and everyone else can (if they look hard enough) see your drunken ramblings. Forard distribution ACLS (immutable) would let you limit distribution to members of a politeness group. Thus - internal, but not external visibility + cancel. Assuming you group your drunken ramblings instead of flinging them to the winds.
But it solves the "domain name hostage" problem for profiles.
Again, its likely a "delete entire profile" command would be built into the protocol.
No. It's a permanent record of the data, or at least as permanent as "until an EMP takes out, simultaneously, all the replicas". Deleting a profile would be tantamount to deleting everything the profile has done in the past, which is tantamount to the historical rewrite, without the "polite consent" of those it's being rewritten out from under.
I'm not sure how you'd deal with "multiple persona" in a reasonable way; you could, I suppose, simply allow it, and allow for mutual adoption and unilateral dissociation - "A adopts B & B adopts A" and "A adopts B and B rejects the adoption", but the storage requirements balloon. For example, I have a number of distinct digital persona that I maintain for reasons of separation of roles, and I'd be sorry to lose that, but I probably would not maintain more than a handful in a social network setting in any case, corresponding to my current social networks and the roles the networks themselves are intended to fulfill. I have a persona on Facebook, I have a persona on LinkedIn, I have a persona on Google+, and so on.
I rather expect that any system that got built on this model would want to be able to subsume, or at lest replica the data and organizational structure from those networks. I think Google Groups / Google Wave / Google+ attempted (and failed) to do this by having groups and groups of groups, but the associative relationships necessary for such a thing are necessarily more complex than the representational geometry of the latest offering(s). It's something you have to design in - you can design large and scale down, but scaling up is a PITA if it requires a redesign. To put it another way: you have to map the absolute problem space, not the intended initial deployment space, with your architecture.
Like I said, I typically do not see a great deal of monteizable value in this, unless you get people to also self-select into profile groups. Perhaps you could get them to do this in exchange for Google Fiber service? I expect most people would do so to avoid paying for Internet service, but it would be a radical rethink of the value of physical communications infrastructure; I expect Verizon et. al. would shit themselves and hire hit men before they'd allow it to happen.