Social Web WG - Account Systems and Webfinger Feedback

[dissolve (Ben Roberts)]

Seeking some feedback, so I’m posting it here as well. I have already had most of this answered on IRC, but figured i’d put it up here to get more eyes on it. (http://btmb.me/s/KP)

Hello, Ben Roberts from the Social Web Working Group and Social Web Incubator Community Group and the W3C (that second one is open to the public if you are interested in joining). I was looking for some feedback.

In yesterday’s Social Web Incubator Community Group telcon, I brought up the issue of WebFinger. The current implementations have had some differences in how they are implemented. Also there are several limitations to it. Its important to investigate what people are doing and what changes they would be open to.

First of all, I would appreciate some feedback about what exactly your project supports, and second I would like to guage interest in implementing some extensions to it. Anything written to replace it would hopefully still support the existing account structure.

First, What characters do you allow in User Names on your local system? What do you allow for federated user accounts. For example some systems do not let you enter a period in the username, but will accept those that do when federating. Do you allow foreign characters in your account names? Emoji?

What do you allow after the @ sign in remote accounts? Is it only domains? (your software must be installed at the root domain) subdirs? subdomains (I would assume everyone does, but best to check). And again, what do you support for federated accounts. Some systems already allow installs in to subdirectories. If you do support subdirs, how do you reconcile this with webfinger lookup? Is it just looking for the .well-know directory inside of that directory?

My current line of thinking is to extend webfinger with a simpler discovery mechanism such as maybe looking up just fetching template at the location given (haven’t determined that part yet). One of the goals of this is to support subdirectory installs and single user domains, or really just plain URLs, but there has to be a mapping between a URL and an account identifier. This creates a few more questions

Do you use @ to refer to local users on the system? If you do this do you allow the period in usernames? This is particularly important as the current ideal is to allow blank usernames for URLs so @ben.thatmustbe.me rather than trying to cram some magic word in to the username section. What would be your level of difficulty with such a system?

What do you think of extending the domain section to actually be a full url path so @www.exampleuniverity.edu/~ben/mysocialapp?

Any other feedback or issues you would like to bring up with the functionality and use of webfinger?

Thank you in advance for any response you give, all feedback is appreciated.

[denschub (Dennis Schubert)]

This feels a little bit redundant to what we discussed on IRC yesterday, but oh well. Also, please see Let's talk about ActivityPub for ActivityPub related discussion, and some of my own personal opinions on the current work.

Providing my $.02 on some of the points raised, allowing some room for others to jump in…

First of all, I would appreciate some feedback about what exactly your project supports

See our federation documentation, which should give you a pretty good insight. If you have any questions, feel free to raise them.

First, What characters do you allow in User Names on your local system?

[A-Za-z0-9_]+

What do you allow for federated user accounts.

Docs here.

What do you allow after the @ sign in remote accounts? […] And again, what do you support for federated accounts.

Valid domain names. That includes subdomains with an unlimited depth.

Some systems already allow installs in to subdirectories. If you do support subdirs, how do you reconcile this with webfinger lookup? Is it just looking for the .well-know directory inside of that directory?

As mentioned on IRC yesterday, we do not support installation into subdirectories and we do not support federating with such systems that are installed inside subdomains. The discovery is described in our docs.

Do you use @ to refer to local users on the system?

This question is ambiguous to me. We always use the full diaspora ID for both displaying and internal tagging. Logging in on the pod, however, works by using only the username (since it would be pointless to provide the domain port as well, since you already are on that servers login site).

[…] allow blank usernames for URLs so @ben.thatmustbe.me rather than trying to cram some magic word in to the username section. What would be your level of difficulty with such a system?

Quoting our IRC discussion:

<ben_thatmustbeme> and just doing things like @ben.thatmustbe.me works but then it becomes an issue where some systems already use @ for local users
<ben_thatmustbeme> what would your thoughts be on allowing things like @ben.thatmustbe.me or @aaron.pk in diaspora
<DenSchub> you mean as usernames?
<DenSchub> we use the @ to split the local part and the host, so if a user would be called "@ben.thatmustbe.me", it would pretty much break everything
<ben_thatmustbeme> DenSchub: yeah, the question is how to refer to site that are userless, most people don't want to refer to an http:// to talk to someone
<ben_thatmustbeme> so using a blank username seems the most logical
<ben_thatmustbeme> also is curlable oddly
<DenSchub> ben_thatmustbeme: imho: looks ugly, also breaks the "looks and works like an email address" part
<DenSchub> not sure if it's a good idea to spec something like a "me@" prefix, but that might turn out to be less bad
<DenSchub> (take that as an idea i had between two meetings, so..)
<ben_thatmustbeme> yeah, we had brought that up too. the issue with any sort of me@ is that it can be a name conflict, unless you just disallow that username
<ben_thatmustbeme> also the email address thing has actually created problems for some people when they don't also own that email address
<SuperTux88> ben_thatmustbeme: blank username wouldn't work with diaspora, but as DenSchub wrote, something like me@ would work
<DenSchub> ben_thatmustbeme: if you allow other users on the host, you probably would not be using "@example.com", because having "foo@example.com" and "@example.com" is even more confusing

That probably sums up our feelings about this and our technical difficulties.

What do you think of extending the domain section to actually be a full url path so @www.exampleuniverity.edu/~ben/mysocialapp?

Also, as mentioned, some systems do support this, we don’t. So far, nobody felt like this was important enough to spent their time on implementing this. That’s all I personally have to say, I’m neither pro or contra, except for thinking that "alice@www.exampleuniverity.edu/~ben/mysocialapp" looks incredibly ugly and is hard to communicate in that real world thingy.

[dissolve (Ben Roberts)]

Thanks for citing the IRC, I know most of it was answered on IRC, just wanted to make sure others had a chance to respond too.

[dissolve (Ben Roberts)]

its also about making sure I asked the exact same questions to every group. I had realized i didn’t think about internationalization originally for example. The links are really helpful to have around as well. Thank you.