4 ms·

What if the ID were similar to a domain name? They stay the same, but the IP address (in this case, the sha1 of the email address) can change. What if the DNS

What if the ID were similar to a domain name? They stay the same, but the IP address (in this case, the sha1 of the email address) can change. What if the DNS model were taken in order to find which social provider a given user was on? That combined with a trust metric (automatically gleaned?) between providers would go a long way, I think...

Qz 16y ago
That seems like building an internet within the internet, which sounds like a lot of redundant work.
theli0nheart 16y ago
Sounds like a pretty interesting idea...can you elaborate a bit more?
- warfangle 16y ago
  Essentially, social platform providers would be hosts to their own users and each users' respective social graph. Nodes in that graph can be native to the platform, or external. External nodes/users can decide how much they want to share with external providers, on a provider-by-provider basis. Each provider, thus, would have a record of how each of its hosted nodes perceives each external provider, trust-wise. In order for a node to find a new external node, they would use their contact's email address. The provider would send a request to all providers it has on record. Depending on how the requestee perceives the requester, he can either ignore or answer the query. If he "knows" the email hash, he can prompt that node/user for permission to send data to the requester - and what level of data to send. If the requestee does not know the hash, the request recursively travels throughout the social platform providers. One of the necessary requirements to being a part of this kind of distributed social network, of course, would be the ability for a user to download their social graph (nodes of email hashes connected to them) and easily port it to another provider. Sort of like exporting your email box contents to bring to another provider. If we throw out the idea of users having unique IDs other than their email address, it would be possible to have different social networks on different providers - e.g., business from one provider and family on another. If a user deemed it, they could potentially also link several email addresses to the same account on one provider. This kind of scheme would have the qualities of being: * Robust: any platform which follows the protocol can participate; Potentially, if a platform goes AWOL, and the nodes within it had sufficient transparency to nodes outside of it, any given provider could rebuild their social graph for them. * Trust: Based on how the nodes on a given provider dole out their social graph / user information to other providers, that provider can perceive the general level of trust its users have about that provider. It can pass this metric on to other providers who request it. * Portability: need I say more? :)
arethuza 16y ago
You would presumably need something like an MX record - but MX records are for all email addresses using that domain. You could probably create individual DNS domains for each user though. So I guess you could give your email provider the ability to publish your social networking provider - but not sure what problem that solves...

Qz 16y ago

That seems like building an internet within the internet, which sounds like a lot of redundant work.

theli0nheart 16y ago

Sounds like a pretty interesting idea...can you elaborate a bit more?

warfangle 16y ago
Essentially, social platform providers would be hosts to their own users and each users' respective social graph. Nodes in that graph can be native to the platform, or external. External nodes/users can decide how much they want to share with external providers, on a provider-by-provider basis. Each provider, thus, would have a record of how each of its hosted nodes perceives each external provider, trust-wise. In order for a node to find a new external node, they would use their contact's email address. The provider would send a request to all providers it has on record. Depending on how the requestee perceives the requester, he can either ignore or answer the query. If he "knows" the email hash, he can prompt that node/user for permission to send data to the requester - and what level of data to send. If the requestee does not know the hash, the request recursively travels throughout the social platform providers. One of the necessary requirements to being a part of this kind of distributed social network, of course, would be the ability for a user to download their social graph (nodes of email hashes connected to them) and easily port it to another provider. Sort of like exporting your email box contents to bring to another provider. If we throw out the idea of users having unique IDs other than their email address, it would be possible to have different social networks on different providers - e.g., business from one provider and family on another. If a user deemed it, they could potentially also link several email addresses to the same account on one provider. This kind of scheme would have the qualities of being: * Robust: any platform which follows the protocol can participate; Potentially, if a platform goes AWOL, and the nodes within it had sufficient transparency to nodes outside of it, any given provider could rebuild their social graph for them. * Trust: Based on how the nodes on a given provider dole out their social graph / user information to other providers, that provider can perceive the general level of trust its users have about that provider. It can pass this metric on to other providers who request it. * Portability: need I say more? :)

arethuza 16y ago

You would presumably need something like an MX record - but MX records are for all email addresses using that domain. You could probably create individual DNS domains for each user though. So I guess you could give your email provider the ability to publish your social networking provider - but not sure what problem that solves...