Proposal: Relationship and Group Scoped Identities

Features
1

I have long been thinking about a way to mitigate the problem with Facebook-style social networks, where knowing somebody means you have direct access to their identity on the system. You can “unfriend” somebody, but you can’t make them forget you.

A simple solution is to create a new identity for each relationship, valid only within that context. (Interestingly, Facebook is using something very similar with their application scoped user ids in their newer API versions.)

MaidSAFE supports any number of identities per person (as a basic consequence of its design), so this is just an application level issue.

How it works: Alice (ID 0) and Bob (ID 1) want to become friends. They generate new identities (2 and 3), and they share it in person (e.g. over NFC or using QR codes), or through a common friend with a Diffie-Hellman kind of setup. (Basically, the relationship assumes its own entity, connecting the two newly created accounts… or something like that.) If Bob turns out to be a jerk :disappointed:, Alice can just throws away the relationship with those IDs :laughing:, and it’s done: Bob has no way to contact her, or to stalk her profile :relieved: – he has never known it in the first place!

This also means that one’s actions across social networks could not be connected, unless he wants them to be. The “real” accounts, logged on to with the Launcher, would act as umbrella identities to group the ever increasing number of relationship scoped identities into more static public profiles.

This scales to groups as well. The group has its own entity, which stores the IDs of the participants. The IDs are created specifically for this group, the original identity of the participants need not be revealed. Adding participants is cheap (if accessing previously published content is acceptable), but removing people would of course need a completely new group, with new group-scoped IDs.

12 Likes
2

Yes, that’s pretty cool. Although if I understand correctly messaging in SAFE requires a unique public name? So other people could still forward that name I suppose.

1 Like
3

Nothing stops you from using multiple unique names at the same time, right?

You have a secret unique name (or more, if so you want, but we’re concerned with only one now); this is the one that you log on to the Launcher with. You don’t share it with people: this is your primary and permanent identity.

When you connect with somebody, you create another unique name, and you make it public for communicating with that one person only. If you want to discard the relationship with this person, you can just throw out this public id, and it’s done: he can’t spam you or anything, because he never knew your “real” identity, just a proxy.

I know it sounds like hoops to go through, but this is almost nothing (just a thin layer on top) compared to how complex the whole system is, and it would be handled for you automatically (in other words, users wouldn’t even have to know about it.)

1 Like
4

But there’s nothing stopping that person from sharing that name with others to contact you.

5

However, you don’t accept communication through that channel only from the counterpart id. If he makes it public, you just disconnect from it, and your original (secret) identity is unaffected. That’s the whole idea.

3 Likes
6

But you can throw that name away and never look at it again - you can disconnect it. Anyone you want to still be able to communicate with you can be given a new -only for them- id to use.

2 Likes
7

Clarification: Your ID of course is your public key. If you send something to my ID, it will arrive encrypted with your public key. If it isn’t, I throw it away, because I know it’s spam. Your can’t share my ID and expect I would receive a message from that other person unless you also give them your private key (i.e. your complete identity.)

1 Like
8

The way I’ve designed the safe exchange:

there is a profile, and inside of a profile is an alias addressbook,

So you can make items and maintain contacts based on an alias. So this way you can separate and represent separately different types of products from the same profile.

You can make unlimited aliases and carry out activities with each separate alias, even manage balances of safecoin or bitcoin using a different alias.

#[derive(Clone, Debug, RustcDecodable, RustcEncodable)]
pub struct Profile {
	pub username: String,
	pub password: String,
	pub alias: Vec<Alias>,
	pub private_key: String,
	pub public_key: String,
}

#[derive(Clone, Debug, RustcDecodable, RustcEncodable)]
pub struct Alias {
	pub name: String,
	pub bitcoin_public_keys: Vec<String>,
	pub bitcoin_private_keys: Vec<String>,
	pub safecoin_public_keys: Vec<String>,
	pub safecoin_private_keys: Vec<String>,
    pub items: Vec<Item>,
    pub selloffers: Vec<SellOffer>,
    pub buyoffers: Vec<BuyOffer>,
    pub public_key: String,
    pub private_key: String,
    pub item_trans: Vec<ItemTransaction>,
    pub coin_trans: Vec<CoinTransaction>,
}

can replace or add more fields for social activities besides trade

9

I kept thinking about this idea and some others, and got carried away a little. I believe there needs to be more fundamental and generic solution; I’ll draw it up in a separate proposal.

2 Likes
10

@happybeing posted a link to this new IBM “Identity Mixer” tech that sounds like it does something similar:

Identity Mixer authenticates users by asking them to
provide a public key. Each user has a single secret key, and it
corresponds with multiple public keys, or identities. Each transaction a
user makes receives a different public key and leaves no privacy
“breadcrumbs.”

11

Much later than planned, here it is: The SAFE Social Network