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…
See our federation documentation, which should give you a pretty good insight. If you have any questions, feel free to raise them.
Valid domain names. That includes subdomains with an unlimited depth.
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.
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).
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 "firstname.lastname@example.org" and "@example.com" is even more confusing
That probably sums up our feelings about this and our technical difficulties.
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 "email@example.com/~ben/mysocialapp" looks incredibly ugly and is hard to communicate in that real world thingy.