Diaspora user directory
Maxi
I have wondered about how we can enable diaspora users to find other
diaspora users by name. People need this to meet someone in the train
and start a relationship later, without needing to ask for a mobile
phone number or diaspora address :-) Of course, users should be able to
choose whether they want to be findable.
I think we do not need a distributed hash table since the names do not
need that much space - a single computer should be able to handle them
all. To achieve decentralicity, we only need synchronisation between
multiple servers, much like the way PGP servers synchronize their keys.
My idea is to take the SKS key server and adapt it to synchronize (full
name, pod url) or (full name, webfinger address) tuples instead.
I have created a github project at
http://github.com/Leberwurscht/Diaspora-User-Directory/wiki, if someone
wanted to help me with this I would be pleased.
Maxi
Dan White
I've been thinking about this problem as well. Another approach is for one
or more Diaspora users/sites to create well known Search Bots that users
voluntarily choose to submit their information to - Their name, high
school, email address, hobbies, interests, or which ever combination of
personal information they're willing to share with that search bot.
When users initially 'friend' the search bot, they establish their personal
information, perform searches based on information others have already
submitted, and sign up for periodic or opportunistic searches.
On the plus side, the design of Diaspora wouldn't have to change much to
accommodate this kind of model - the network API would have to define each
of the types of messages passed to and from search bots, but they would
still be end-to-end types of messages. Another advantage is that if a user
decides that she no longer trusts a search bot with her personal
information, she can choose another one.
The down sides are pretty obvious. Searches on the Diaspora network would
be a little split brained, since there wouldn't be one authority for
user search data.
--
Dan White
Bastian Hoyer
with malicious content) to the directory ?
With PGP you would always only trust a key if you have other ways to
contact the person and make sure it is his key, but without asking for
a mobile number, email or something like that how could you ever be
sure that the person you found in that diaspora directory is the one
you met in reality ?
According submitting information to search bots... i thought diaspora
is about keeping control over your information... if you commit
information to bots/synced directories you even have less controll
about your information then you currently have at facebook.
How would you update the directory if you move your page? How would
you make sure nobody else can update the entry? What could someone do
against imposters in those directories ?
Dan White
>How would you prevent imposters to create an submit fake pages (maybe
>with malicious content) to the directory ?
I don't think it's within Diaspora's capabilities to prove that any given
Diaspora ID matches up with a person.
>With PGP you would always only trust a key if you have other ways to
>contact the person and make sure it is his key, but without asking for
>a mobile number, email or something like that how could you ever be
>sure that the person you found in that diaspora directory is the one
>you met in reality ?
I agree. It's best to have a key signing party with individuals you wish to
have a strong online trust with, but users will still want to search for
that friend they knew in high school, who may have gotten married and
changed their last last.
On Facebook, I'm willing to accept that if I search for and send a friend
request to someone I haven't seen in 10 years, that person might not really
be who I think they are. I can usually develop *some* level of trust after
a few postings, seeing who our mutual friends are, and after seeing their
pictures.
>According submitting information to search bots... i thought diaspora
>is about keeping control over your information... if you commit
>information to bots/synced directories you even have less controll
>about your information then you currently have at facebook.
Well, you only submit what you want to give to a search bot. You only
control information as long as you don't give it out (regardless of whether
it's a search bot or a friend). If you only want to provide a name
association with your Diaspora ID, that works.
>How would you update the directory if you move your page? How would
>you make sure nobody else can update the entry? What could someone do
>against imposters in those directories ?
When you establish a friendship with the search bot, your search bot has
your public key, which prevents anyone else from updating your information.
If you move to a new server (however that would happen), you can still use
your private key to update your information.
The key is to make sure that someone else cannot impersonate your Diaspora
ID. I think that's about the only assurance you could have with a search
bot. Anyone else, of course, could claim to be you and post your pictures
in their own profile, under the guise of another Diaspora ID.
I don't know how Diaspora could provide any kind of assurance that Dan
White, of 1234 East Johnson Street, is dwh...@olp.net, without using some
3rd party trust, such as having a government entity tying your Diaspora ID
to something like a Driver's License database.
--
Dan White
Rich Price
already exist for two seeds in the same pod? We should not
decide on inter pod communication until we have rigorously
defined intra pod communication. This way we will have a
stationary target to shoot at.
michael chrisco
facebook. Except its "default off" for people to discover you and if
you put it on, people can search your name/find you using AI/
ect...ect...
michael chrisco
is the main focus of such a development.
The more ways we can connect people the better. I do believe all
features that give information to others should be "auto off" before
activated on. That way, we dont have to deal with issues with privacy
later.
Sorman
Public webfinger profiles must be indexed by search engines.
Maxi
Small pods may have problems to get into the google index, and it might
take a long time. Moreover, it would be nice to be independent of google
or other search engines.
The main disadvantage I think is that google won't provide an API for
searching diaspora users, but searching for users should be integrated
in the diaspora user interface.
Maxi
Maxi
> I've been thinking about this problem as well. Another approach is for
> one
> or more Diaspora users/sites to create well known Search Bots that users
> voluntarily choose to submit their information to - Their name, high
> school, email address, hobbies, interests, or which ever combination of
> personal information they're willing to share with that search bot.
>
> When users initially 'friend' the search bot, they establish their
> personal
> information, perform searches based on information others have already
> submitted, and sign up for periodic or opportunistic searches.
just would concentrate on basic information like full name and hometown
first and add synchronisation between these search servers. If every
search server has the same information, search will not be split brained.
Moreover, I would prefer that seeds push their information to the
directory instead of having search bots pull periodically from the seeds.
>
> On the plus side, the design of Diaspora wouldn't have to change much to
> accommodate this kind of model - the network API would have to define
> each
> of the types of messages passed to and from search bots, but they would
> still be end-to-end types of messages. Another advantage is that if a
> user
> decides that she no longer trusts a search bot with her personal
> information, she can choose another one.
information. Every information a search engine gets has to be considered
as public. I don't know the diaspora source well enough to know whether
it would be simple to extend the friending mechanism in a way that the
friend only gets the full name and perhaps (this should be configurable)
the hometown, but nothing else. And I think the diaspora interface
should provide separate interfaces for submitting information to a user
directory and for friending users, otherwise someone searching for this
functionality will never guess right how to do it.
Maxi
information. As Dan says, we can only prevent users from updating
someone else's entry in the user directory using cryptographic methods,
and I'll try to do that.
Until now, I have been trying to find my way through the SKS code, which
is difficult because I have never done anything in ocaml. But I
succeeded in writing a basic socket server and client using modules from
SKS. If someone wants to join the work, I take notes at
http://github.com/Leberwurscht/Diaspora-User-Directory/wiki/SKS.
Maxi
Anders Feder
Dan White
>Am 17.10.2010 06:44, schrieb Dan White:
>> I've been thinking about this problem as well. Another approach is for
>> one or more Diaspora users/sites to create well known Search Bots that
>> users voluntarily choose to submit their information to - Their name,
>> high school, email address, hobbies, interests, or which ever
>> combination of personal information they're willing to share with that
>> search bot.
>>
>> When users initially 'friend' the search bot, they establish their
>> personal information, perform searches based on information others have
>> already submitted, and sign up for periodic or opportunistic searches.
>
>This is not so different from my approach if I understand you right. I
>just would concentrate on basic information like full name and hometown
>first and add synchronisation between these search servers. If every
>search server has the same information, search will not be split brained.
>Moreover, I would prefer that seeds push their information to the
>directory instead of having search bots pull periodically from the seeds.
My understanding of your original proposal was to have a group of pgp key
servers that synchronized with each other and could be used by end users to
retrieve keys by name, pod url, or webfinger address.
I think a problem to consider is how to define what invalid keys are and
prevent them from entering one of the pgp key servers and getting
propagated. For example, how would you prevent someone from introducing an
invalid or nefarious (full name, pod url) key?
My approach also suffers from this problem, which is why I think it's best
to more tightly integrate it into diaspora so that it can use some
pod-to-pod authentication/authorization or end-to-end semantics (whatever
they may be) to prevent invalid keys from being seen.
>> On the plus side, the design of Diaspora wouldn't have to change much to
>> accommodate this kind of model - the network API would have to define
>> each of the types of messages passed to and from search bots, but they
>> would still be end-to-end types of messages. Another advantage is that
>> if a user decides that she no longer trusts a search bot with her
>> personal information, she can choose another one.
>
>I do not think that any search bot should be able to access personal
>information. Every information a search engine gets has to be considered
>as public. I don't know the diaspora source well enough to know whether
>it would be simple to extend the friending mechanism in a way that the
>friend only gets the full name and perhaps (this should be configurable)
>the hometown, but nothing else. And I think the diaspora interface
>should provide separate interfaces for submitting information to a user
>directory and for friending users, otherwise someone searching for this
>functionality will never guess right how to do it.
After considering it some more, I think the idea of friending a search bot
should just be the same function of two identities friending each other,
and giving the ability of a new friend to share your information with his
or her friends, restricted in some way by the information you shared with
that new friend, and by information you're authorizing them to share with
their other friends.
A search bot could just be an approximation of diaspora user who's got a
huge friend list.
That way you don't have to have a user directory. You can use your Aspects
(say, Jefferson Highschool, Justin Beiber Fan Club, Underwater Basket
Weaving, and Gothom City Computer Club) to find others with those
interests. Maybe your Jefferson Highscool aspect has a couple of friends
who are really popular and introduce you to new classmates, or maybe
Jefferson Highschool decides to create a seed itself that all classmates
friend, and use to search for other classmates.
Diaspora would have to create some capability to share friends lists with
other friends, and in a secure way.
On 24/10/10�18:00�+0200, Anders Feder wrote:
>In the spirit of doing one thing and doing it well, I would much prefer if
>this functionality was external to Diaspora itself. Pods would be free to
>link in various ways to directories, of course, but the directories ought to
>exist on separate web servers and not rely on significant integration with
>the main Diaspora distribution code base.
If it's external, then it becomes more difficult (but probably not
impossible) to validate the information in a directory.
It becomes a bit easier if you allow a pod for a domain, such as
example.net, to be authoritative in some way for the public keys for all
users in its pod/domain.
>Maybe Diaspora could have an API for exporting a list of the users hosted on
>the pod. The owner of the pod (or someone else) could then submit the
>address of the pod to an directory, and the directory would take care of
>importing the list of users on the pod via the API. It would then be up to
>the directory to make this information available in the most useful fashion
>- perhaps it would upload it to an even bigger "upstream" directory, perhaps
>it would combine the information with user lists from Facebook and other
>social networks, perhaps it would publish the information on a P2P network,
>etc. This should not be up to us to dictate.
>
>If this is basically what you had in mind, consider this my "+1"
With a per-aspect approach, you'd have the ability to provide more fine
grained information, or perhaps even conflicting information to persons who
are attempting to search for you via a classmate as opposed to a
professional contact.
For instance, you might tell Jefferson Highschool Class of 2000 that you're
divorced, with interests in computers, hiking and reading. You might
neglect to tell professional contacts what your marriage status is, and that
your interests are Open Source, Linux, and that you're looking for a job.
--
Dan White
shadowfirebird
social network"? I'm not expressing an opinion here, just asking a
question.
When we are talking about finding people you have never met, or met so
long ago that it hardly counts for purposes of authentication, then
what exactly does "privacy" mean in this context?
I know it's been pointed out that after chatting with someone for a
while you can get a feeling if the person is the one you remember, but
that's an out-of-band thing. I'm not saying it doesn't work -- I done
it myself -- just that you can do it in Facebook, and Diaspora is
supposed to be more "privacy aware" than Facebook...
One approach, I guess, is to say that Diaspora should facilitate
authentication between individuals if they want it, but shouldn't
insist on it.
Dan Brickley
<shadowf...@gmail.com> wrote:
> Can I just ask how all this fits in with the idea of a "privacy-aware
> social network"? I'm not expressing an opinion here, just asking a
> question.
>
> When we are talking about finding people you have never met, or met so
> long ago that it hardly counts for purposes of authentication, then
> what exactly does "privacy" mean in this context?
Privacy-aware doesn't mean we can't talk with strangers, or make
public information about ourselves in a form that helps others find
us. Just that the UI and engineering story is put together in a way
that leaves users in control, gives them sufficient understanding of
the risks and benefits, and treats users primarily as humans rather
than as inventory in an advertising network.
The Web is a wonderful thing in large part because it allows strangers
to meet, collaborate, share, connect and all that good stuff. Helping
users avoid accidental over-sharing, rather than pushing them towards
it, is the harder-than-it-looks problem here. Especially when those
users are teens or early 20s who feel immortal, have never had to
worry, have never done anything seriously wrong or made serious
enemies.
cheers,
Dan
Dan White
>Can I just ask how all this fits in with the idea of a "privacy-aware
>social network"? I'm not expressing an opinion here, just asking a
>question.
>
>When we are talking about finding people you have never met, or met so
>long ago that it hardly counts for purposes of authentication, then
>what exactly does "privacy" mean in this context?
Privacy, in my opinion, means that you can send a private message to any
given Diaspora user id with the expectation of privacy... that is, that
your (sha...@dev.null) communication with a given user (dwh...@domain.com)
will not be intercepted by another party or other diaspora
user/administrator.
>I know it's been pointed out that after chatting with someone for a
>while you can get a feeling if the person is the one you remember, but
>that's an out-of-band thing. I'm not saying it doesn't work -- I done
>it myself -- just that you can do it in Facebook, and Diaspora is
>supposed to be more "privacy aware" than Facebook...
>
>One approach, I guess, is to say that Diaspora should facilitate
>authentication between individuals if they want it, but shouldn't
>insist on it.
If the system can't guarantee privacy between any two given diaspora users
(who perhaps have never met each other), then diaspora probably becomes
something unfriendly on a large scale (like email with GPG), because you
can't really boot strap the system in a secure way without some other way
for two users to establish trust.
I think there's value in reputation in a social network... that is, friends
of my friends have some level of trust value with me. The more friends we
have in common (or the more friends we have in common that matter), the
more value I may choose to place in their claimed identity.
--
Dan White
Maxi
>
> My understanding of your original proposal was to have a group of pgp key
> servers that synchronized with each other and could be used by end
> users to
> retrieve keys by name, pod url, or webfinger address.
synchronisation algorithm. So when reading again your idea, I think our
approaches differ a bit.
>
> I think a problem to consider is how to define what invalid keys are and
> prevent them from entering one of the pgp key servers and getting
> propagated. For example, how would you prevent someone from
> introducing an
> invalid or nefarious (full name, pod url) key?
hometown. But it should be possible to prevent users from manupulating
other users' entries and also to prevent users from submitting pod urls
they don't control. I will think about this.
> My approach also suffers from this problem, which is why I think it's
> best
> to more tightly integrate it into diaspora so that it can use some
> pod-to-pod authentication/authorization or end-to-end semantics (whatever
> they may be) to prevent invalid keys from being seen.
detail? If we must rely on pods to prevent users from submitting invalid
information, this won't help, because everyone can make his own, even
single-user, pod.
>
> After considering it some more, I think the idea of friending a search
> bot
> should just be the same function of two identities friending each other,
> and giving the ability of a new friend to share your information with his
> or her friends, restricted in some way by the information you shared with
> that new friend, and by information you're authorizing them to share with
> their other friends.
>
> A search bot could just be an approximation of diaspora user who's got a
> huge friend list.
>
> That way you don't have to have a user directory. You can use your
> Aspects
> (say, Jefferson Highschool, Justin Beiber Fan Club, Underwater Basket
> Weaving, and Gothom City Computer Club) to find others with those
> interests. Maybe your Jefferson Highscool aspect has a couple of friends
> who are really popular and introduce you to new classmates, or maybe
> Jefferson Highschool decides to create a seed itself that all classmates
> friend, and use to search for other classmates.
>
> Diaspora would have to create some capability to share friends lists with
> other friends, and in a secure way.
some other advantages, for example it can be used to implement a "friend
suggest" function, and I don't object that something like this should be
integrated in diaspora.
My approach is more like a traditional telephone book, that has a right
to exist on its own since it solves a slightly different problem.
> If it's external, then it becomes more difficult (but probably not
> impossible) to validate the information in a directory.
>
> It becomes a bit easier if you allow a pod for a domain, such as
> example.net, to be authoritative in some way for the public keys for all
> users in its pod/domain.
the sks server is written in ocaml and I will use parts of it, and
because I think validation would not become simpler even if I would
integrate it into diaspora.
I do however not see either how integrating will make validation simpler
for your approach.
Maxi
Dan White
>Am 24.10.2010 18:59, schrieb Dan White:
>> My approach also suffers from this problem, which is why I think it's
>> best to more tightly integrate it into diaspora so that it can use some
>> pod-to-pod authentication/authorization or end-to-end semantics
>> (whatever they may be) to prevent invalid keys from being seen.
>
>I don't see how this can solve the problem. Can you explain this in more
>detail? If we must rely on pods to prevent users from submitting invalid
>information, this won't help, because everyone can make his own, even
>single-user, pod.
I would propose that public keys of any given diaspora user are retrieved
from that user's pod, and that pods are judged to be authoritative for any
public keys of it's users. E.g. the pod for example.net would be trusted to
provide a valid public key for user jsm...@example.net.
When rsm...@domain.com wants to send an invite to jsm...@example.net, it
(or it's pod) would ask the pod of example.net for jsm...@example.net's
public key. It could sign a trust on that key (to prove it's own
identity) and send a friend request to jsm...@example.net.
The pod for example.net, after receiving the friend request, would retrieve
rsm...@domain.com's public key and verify that the friend request really
was sent from him, then present the friend request to it's own
jsm...@example.net. If jsm...@example.net approves, then he signs a trust
on rsm...@domain.com's key.
Both rsm...@domain.com and jsm...@example.net could then announce (if they
wish to) their friendship to their other friends by transmitting both
trust signs to prove it.
If either of them wishes to unfriend the other, they'd issue a trust revoke
on the other's key, and distribute to those it wants to know.
>> After considering it some more, I think the idea of friending a search
>> bot should just be the same function of two identities friending each
>> other, and giving the ability of a new friend to share your information
>> with his or her friends, restricted in some way by the information you
>> shared with that new friend, and by information you're authorizing them
>> to share with their other friends.
>>
>> A search bot could just be an approximation of diaspora user who's got a
>> huge friend list.
>>
>> That way you don't have to have a user directory. You can use your
>> Aspects (say, Jefferson Highschool, Justin Beiber Fan Club, Underwater
>> Basket Weaving, and Gothom City Computer Club) to find others with those
>> interests. Maybe your Jefferson Highscool aspect has a couple of friends
>> who are really popular and introduce you to new classmates, or maybe
>> Jefferson Highschool decides to create a seed itself that all classmates
>> friend, and use to search for other classmates.
>>
>> Diaspora would have to create some capability to share friends lists
>> with other friends, and in a secure way.
>
>But this approach does not solve the "met in the train" problem. It has
>some other advantages, for example it can be used to implement a "friend
>suggest" function, and I don't object that something like this should be
>integrated in diaspora. My approach is more like a traditional telephone
>book, that has a right to exist on its own since it solves a slightly
>different problem.
I think it solves the same problem, but in a slightly different way :)
With my solution, those two train passengers just exchange diaspora ids,
which would be just like exchanging email addresses today. As long as
diaspora can provide an expectation of privacy between any two diaspora
users, then that works. Those two passengers have just completely a key
signing party, of sorts.
>> If it's external, then it becomes more difficult (but probably not
>> impossible) to validate the information in a directory.
>>
>> It becomes a bit easier if you allow a pod for a domain, such as
>> example.net, to be authoritative in some way for the public keys for all
>> users in its pod/domain.
>
>I think for my approach, it is more simple to make it external, since
>the sks server is written in ocaml and I will use parts of it, and
>because I think validation would not become simpler even if I would
>integrate it into diaspora.
>
>I do however not see either how integrating will make validation simpler
>for your approach.
My proposal would be to make all key exchanges based on GPG (OpenPGP)
protocols.
--
Dan White
Dr.Paulaner
signed in another seed,that my server does find him in the
diasporaweb; so that server 2 server data exchange feature is still
missing; is this right?
or did i NOT configure an config file?
Marcel
michael chrisco
communicating (still waiting on a .dom), but no confederation between
different diaspora servers.
Maxi
> I would propose that public keys of any given diaspora user are retrieved
> from that user's pod, and that pods are judged to be authoritative for
> any
> public keys of it's users. E.g. the pod for example.net would be
> trusted to
> provide a valid public key for user jsm...@example.net.
>
> When rsm...@domain.com wants to send an invite to jsm...@example.net, it
> (or it's pod) would ask the pod of example.net for jsm...@example.net's
> public key. It could sign a trust on that key (to prove it's own
> identity) and send a friend request to jsm...@example.net.
>
> The pod for example.net, after receiving the friend request, would
> retrieve
> rsm...@domain.com's public key and verify that the friend request really
> was sent from him, then present the friend request to it's own
> jsm...@example.net. If jsm...@example.net approves, then he signs a trust
> on rsm...@domain.com's key.
>
> Both rsm...@domain.com and jsm...@example.net could then announce (if
> they
> wish to) their friendship to their other friends by transmitting both
> trust signs to prove it.
>
> If either of them wishes to unfriend the other, they'd issue a trust
> revoke
> on the other's key, and distribute to those it wants to know.
transfer this to your "search bots as friends" idea, jsm...@example.net
is such a search bot. This bot must work automatically, so it has to
accept all friendship requests it gets, and these friendship requests
can come from arbitrary pods. Someone wanting to harm diaspora can set
up a fake pod with a lot of fake seeds and flood the search bot with spam.
>> But this approach does not solve the "met in the train" problem. It has
>> some other advantages, for example it can be used to implement a "friend
>> suggest" function, and I don't object that something like this should be
>> integrated in diaspora. My approach is more like a traditional
>> telephone
>> book, that has a right to exist on its own since it solves a slightly
>> different problem.
>
> I think it solves the same problem, but in a slightly different way :)
>
> With my solution, those two train passengers just exchange diaspora ids,
> which would be just like exchanging email addresses today. As long as
> diaspora can provide an expectation of privacy between any two diaspora
> users, then that works. Those two passengers have just completely a key
> signing party, of sorts.
exchange diaspora ids. This difference might appear insignificant, but
that's the problem I want to solve :-)