Re: Finding user profiles on a Social Net

> Simon Tennant <mailto:simon@buddycloud.com>
> 11 June 2013 18:01
> 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 
> <http://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.
>
>
>
The way Webfinger suggests to deal with this is to 301 Moved Permanently 
your /.well-known/, but I can understand the trickiness of that.

If the outside firm is also hosting the website, I understand the 
difficulty. If it's hosted internally (but the outside firm are 
maintaining it), then redirecting well-known should be no more than a 
couple of lines in the web server configuration.

As you've said BuddyCloud is based upon XMPP, then a DNS based solution 
just makes sense there anyway (because XMPP is already using SRV records)
>
>
>
>
> -- 
> Simon Tennant | buddycloud.com <http://buddycloud.com> | +49 17 8545 
> 0880 | office hours: goo.gl/tQgxP <http://goo.gl/tQgxP>
> Nick Jennings <mailto:nick@silverbucket.net>
> 11 June 2013 17:46
> 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
>
>
>
>
> Michał 'rysiek' Woźniak <mailto: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. :/
>
> Simon Tennant <mailto:simon@buddycloud.com>
> 11 June 2013 11:55
> Hi Melvin
>
> There's two problems to be solved.
>
> 1. How to find the responsible server for a domain's social network. 
> (Which server runs the social network functions for EXAMPLE.COM 
> <http://EXAMPLE.COM>?)
> 2. How clients find their API endpoint (user@EXAMPLE.COM 
> <mailto:user@EXAMPLE.COM> is trying to log-in on a new 
> mobile-social-app, what API endpoint do I use for EXAMPLE.COM 
> <http://EXAMPLE.COM>)
>
> The first problem is solved using SRV records or webfinger or whatever
>
> The second problem is solved using DNS-SD. The lookup is "magically" 
> simple. In buddycloud's case the mobile client will do the following 
> query:
>
> dig -t TXT _buddycloud-api._tcp.EXAMPLE.COM <http://tcp.EXAMPLE.COM>. 
> +short
>
> and get back the following easily parseable content:
>
> "v=1.0" "host=demo.buddycloud.org <http://demo.buddycloud.org>" 
> "protocol=https" "path=/api" "port=443"
>
> To make this work you just need to add something like the following to 
> your zone file.
> _buddycloud-api._tcp.EXAMPLE.COM <http://tcp.EXAMPLE.COM>. IN TXT 
> "v=1.0" "host=buddycloud.EXAMPLE.COM <http://buddycloud.EXAMPLE.COM>" 
> "protocol=https" "path=/api" "port=443"
>
> So for your app, just change _buddycloud-api to whatever you would 
> like (and if you are creating new protocols, be nice and register them 
> with IANA).
>
> S.
>
>
>
>
>
> -- 
> Simon Tennant | buddycloud.com <http://buddycloud.com> | +49 17 8545 
> 0880 | office hours: goo.gl/tQgxP <http://goo.gl/tQgxP>
> Melvin Carvalho <mailto:melvincarvalho@gmail.com>
> 11 June 2013 11:13
>
>
>
> On 6 June 2013 16:41, Simon Tennant <simon@buddycloud.com 
> <mailto:simon@buddycloud.com>> wrote:
>
>     I generally dislike /.well-known because it makes lots of
>     assumptions about the web-root being available.
>
>     Three problems with this:
>     1.  Others might run hosted personal pages like those hosted on
>     about.me <http://about.me>. For example my sister runs a hosted
>     store on her domain. Short of getting the eCommerce provider to
>     change their code, she would never be able to implement anything
>     social.
>
>     2.Often times an organization will have their web-root maintained
>     by another company. Page updates could easily overwrite a nice
>     /.well-known hierachy.
>
>     3. I don't know the answer to this, but how long should
>     /.well-known be considered authoritative? What kind of refresh
>     interval?
>
>     When you start thinking about it, this is all a hack to accomplish
>     what DNS already does. DNS-SD has already solved this, and has
>     caching, and with zone signing, authority.
>
>
> Hi Simon, I got a reply from stuart re this:
>
> "DNS-SD is not magical. It really just does one simple thing -- where 
> a user would have to type in an IP address, instead they can select 
> from a list. So if you have something where today the users would have 
> to set it up by typing in addresses, then DNS-SD can simplify that step."
>
> It's quite interesting.  I'm still trying to get my head around how 
> this could be used, though ... :)
>
>
>     S.
>
>
>
>
>     On 6 June 2013 16:22, Melvin Carvalho <melvincarvalho@gmail.com
>     <mailto:melvincarvalho@gmail.com>> wrote:
>
>         I was thinking about the issue of finding user profiles on a
>         social net, and it's not always easy to know where a user's
>         data will be located.  There seems to be no well known place
>         to get user information from a profile.  Which means it's
>         harder for HTTP based social web users to talk to each other.
>
>         One increasingly popular method is to use the /.well-known/
>         directory.  The disadvantage of this approach is that is it
>         pretty rigid and people say it amounts out of band hard
>         coding.  However one advantage is that it can save a round
>         trip, compared with follow your nose, and it can client
>         implementations more straight forward.
>
>         Taking the well known directory a logical pattern might be to
>         register:
>         *
>         *
>         */.well-known/user/bob*
>
>         For the FSW?
>
>
>         /Would it allow redirects/ -- I would say yes.
>
>         /What would it return/ -- I would suggest linked data. 
>         Ideally a browser would see html and an ajax request would see
>         JSON, but you could start with just one of the two, say JSON only.
>
>
>         Good idea / bad idea / too hard to implement ... thoughts?
>
>
>
>
>     -- 
>     Simon Tennant | buddycloud.com <http://buddycloud.com> | +49 17
>     8545 0880 <tel:%2B49%2017%208545%200880> | office hours:
>     goo.gl/tQgxP <http://goo.gl/tQgxP> 
>
>