I suspect they're still on a gradual roll-out strategy, not fully public.
Their site is still quite tech-focused, not an end-user product presentation. That may be because they wanna build an ecosystem for many of the complex bits of the architecture. To learn yet another lesson from other protocols: have solid libs, frameworks and tools in place to make solution designers happy.
And keep the lead, of course.
Phone no. signup. Another deliberate friction, to avoid unmanageable influx?
@smallcircles i'm aware they say anyone can spin up a relay, what i'm saying here is that while that is technically true, it is not in practice possible to not use the main relay. even if anyone can spin up a relay, if all your friends subscribe to feeds that draw from the main relay (and they would have no way of knowing that was the case, since relay choice is doubly obscured through app views and feed generators), who cares?
agreed that "big graph server" was a huge branding miss and renaming it to relay is very funny.
the PDF linked in OP is titled "Usable Decentralized Social Media" - one thing's for sure, they are end-user product presentation first. they did not develop the backend server technology and then the client. they developed the client and then the backend server technology. this is actually super important to what is going wrong here - they imagine the primary problem with decentralized social media being that people don't want to see complexity, and thus an algorithmic marketplace where everyone provides for you, the hapless consumer, is the only solution.
and omfg i did not know they were doing PHONE NUMBER SIGN UP when their ENTIRE PROTOCOL is designed around PORTABLE IDENTITY. the FIRST ITEM in the protocol overview is "Users are identified by domain names on the AT Protocol."
@smallcircles i'm aware they say anyone can spin up a relay, what i'm saying here is that while that is technically true, it is not in practice possible to not use the main relay. even if anyone can spin up a relay, if all your friends subscribe to feeds that draw from the main relay (and they would have no way of knowing that was the case, since relay choice is doubly obscured through app views and feed generators), who cares?