Re: Finding user profiles on a Social Net

I really don't think this matters: each federated social network will have
a different use case.

Webfinger works well when you control the entire stack / have everything
running on one box.

In our experience, customers installing buddycloud instances have a
marketing firm looking after their "shop-window"/example.com website and a
dev-ops team installing buddycloud software. The dev-ops wouldn't want the
outside webfirm touching their DNS and the webfirm wouldn't want to be
minding to not touch a .hosts-meta on the hosting platform.

So in buddycloud's case DNS makes more sense. There's no right way or wrong
way: just use what works for your own project and document it well.

S.




On 11 June 2013 18:46, Nick Jennings <nick@silverbucket.net> wrote:

> I agree with Owen,
>
>  Although I've managed my own DNS servers many times in the past, I now
> offload that service to my domain registrar for a number of reason,
> convenience and uptime being the primary.
>
>  Most registrars do not have programmable APIs to automatically update DNS
> records (unless you pay big money for the professional DNS service
> providers).
>
>  This means that, in order for most people to play ball, they will have to
> go use their providers web-interface to update their DNS records everytime
> they want to make a change for lookup.
>
> Setting aside the DNS learning curve for newcomers, out of sheer
> inconvenience this not a process I'd voluntarily sign up for :)
>
> -Nick
>
>
>
>
> On Tue, Jun 11, 2013 at 6:29 PM, Owen Shepherd <owen.shepherd@e43.eu>wrote:
>
>>
>>   Michał 'rysiek' Woźniak <rysiek@fwioo.pl>
>>  11 June 2013 15:32
>>
>> +1
>>
>> That would be the best solution, but no social network software I know of
>> implements it. Instead, webfinger is being used. :/
>>
>>
>>  What concrete advantages do you get from DNS-SD over Webfinger? All I
>> see is the negative that now you have to have DNS control of your domain,
>> in addition to HTTP control, and it still doesn't answer the question of
>> how you do user discovery.
>>
>> Webfinger provides the ability to do both:
>>
>>    - rel="about", rel="self" or rel="alternate"  (just pick one and run
>>    with it) can be used to link to the user's profile page, API "profile" and
>>    various other information. Hypothetically: [
>>    {"rel":"self", "type":"text/html", "href":
>>    "https://example.org/~person" <https://example.org/~person>},
>>    {"rel":"self", "type":"application/stream+json", "href":
>>    "https://api.example.org/user/person"<https://api.example.org/user/person>
>>    },
>>    {"rel":"self", "type":"text/vcard", "href":
>>    "https://api.example.org/user/person/vcard"<https://api.example.org/user/person/vcard>
>>    },
>>    {"rel":"self", "type":"application/vcard+xml", "href":
>>    "https://api.example.org/user/person/vcard.xml"<https://api.example.org/user/person/vcard.xml>
>>    }]
>>    - Custom relations can be used to link to whatever API endpoints the
>>    user needs. For example, Pump.io uses the (presently unregistered)
>>    "activity-inbox" and "activity-outbox" links (these are, of course, user
>>    dependent)
>>    - Finally, you might need other relationships for client associations
>>    (i.e. OAuth and similar). They could be located either in the WebFinger
>>    response for the user (may reduce the number of requests required) or in
>>    the host metadata
>>
>> I don't get why one would suggest combining both WebFinger and DNS-SD in
>> one specification. Why complicate matters unnecessarily?
>>
>> Particularly when, outside (apparently) some large corporations, DNS
>> configuration is a far higher hurdle than adding something to the web root.
>> If we struggle to get people to deploy these applications today, when
>> mostly they just require uploading and connecting to a database... how much
>> harder will it be when they also have to add complex TXT records to their
>> DNS?
>>
>
>


-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP