AT-Communities #1: the Concierge, the Vault, and the Fuck-ass Astro Website

In which I try to make sense of communities on ATproto.

Table of Contents

This article comes after reading Daniel’s thoughts on Bluesky’s move towards Community, when Boris torpedoed my week wisely suggested I say something on the topic of ATproto Communities.

If you haven’t heard much about them yet, the shallower end of my feelings is best summed up by what I told Boris right as I closed off Daniel’s article:

“I want Bluesky to own my community just as much as I want Bluesky to own my PDS¹”

And that—hasty disclaimer before the “Yeah! Fuck Bluesky!” starts—is a non-zero amount. Indeed, Bluesky currently holds not only my personal PDS, but the username others @ me by. And I’m fine with that! Genuinely!

If you balk at this, consider I have solid reasons for not moving off my cozy defaults:

1. I’m lazy and busy and lazy
2. For any reason I want, whenever the urge eventually hits, I can swap out the service hosting my data² and ditch Bluesky forever—so I feel no particular pressure to do so right now.

Similarly, if I’m ever to kick off my shoes, relax, and trust Bluesky—any service, really!—with hosting a community I “own”³, then everything surrounding the community’s identity and function needs at least as much “credible exit” as a PDS does.

Put plainly:

To live up to the protocol’s original promise, an ATproto Community must be able to leave a rogue service with everything it needs to take root somewhere else—far, far away from its reach—with as little disruption as possible.

Luckily, that’s exactly what Daniel and the others who’ve been working on this have been building and writing essays about⁴! So this article is not me barging in, shining armor on, rectifying something that’s about to go wrong. This is just me—who’s been prodding the protocol, building a prototype of an ATproto Community, and spending a few years looking at “how the fuck do we community”—finally getting off my ass and writing down what I know, believe, and have been taught about how we should do community on ATproto.

And to start, I’m going straight to the million dollars question…

What is an ATproto Community?

It’s hard to define what “a community” is, but here’s some of what a community is not: a community is not the place people meet; a community is not its members; a community is not its admins, moderators, or (for what it’s worth) its “owners”. In a way, “a community is an idea vibe, and ideas vibes are bulletproof unknowable”.

What’s very much knowable, however, is that once you build a technology that connects people across the web—like ATproto does—people will soon yearn for more than just sharing porn expressing themselves. They will seek to build “group spaces” to share porn find belonging in a larger whole. And now that the moment has come for us, folks are racking their brains (together!) so ATproto Communities can live on this protocol the way a user does—owning their identity, their data, and their freedom to fire any service that stops meeting their needs.

And here’s the lucky deal: we don’t need to define community to design how Communities may be done on ATproto! Or at least, it seems many are hovering around similar ideas, no matter what shape the concept holds in their brain.

Thus, a Community on ATproto will likely have:

• Its own DID—that is, its own independent identity in the larger ATmosphere
• Its own PDS—that is, its own place to hold its own data
• Some “entity” that can read and write data on its behalf—often referred to as “the Arbiter”, after Zicklag’s conceptualization of it

This is accepted enough that we may as well consider it settled—or “almost settled”, to be precise. Even as the general shape is taking hold, the third piece—that entity that acts on the Community’s behalf—remains slippery, with everyone grasping at its edges just to see it unravel against some particularly sharp corner…

The Thankless Job(s) of the Arbiter

Last week, Zicklag generously lent me some time to walk through the Arbiter’s design together. My plan was to learn its more practical ins and outs, so I could jump on stream myself and walk less-technical “AT-izens” through the shape of ATproto Communities—something now postponed (not replaced) by this article.

For the curious (and only the curious), here’s the resulting diagram⁵. It was never meant as anything more than notes to myself, and it’s not required to read the rest—if you, like me, hate spoilers, it may even detract.

Full page

1x 2x 4x

I crave those spoilers

Cutting a long discussion short, Zicklag and I spent the afternoon teasing apart the Arbiter’s various responsibilities, which (Zicklag explained) have evolved alongside the concept. What started as a single block of functionality is now “separating” into distinct, potentially independent roles:

• Custodian of the keys, holding the credentials to read and write the Community’s data
• Member Manager, knowing who’s a Member of the Community and who’s allowed to do what
• Community Host, keeping track of the public and private spaces of the Community, and fetching data on the Community’s behalf

Of course, I’ve been rotating all this in my brain ever since. And as I rotated, I kept circling back to a thought: these aren’t just roles, they’re jobs. Jobs that a Community should be able to hire (and fire!) for, jobs that—Zicklag said so himself—could in principle be taken up by a different service, run by a different party, and swapped out independently.

But if each exists on its own, then a Community looks less like DID + PDS + Arbiter, and more like a complex weave of jobs to be done, relationships to maintain, and Members to serve: all requests swiftly routed or handled; each credential continuously checked; and information properly filed and retrieved—across countless members, roles, guests and “hired hands”.

Which means a Community needs more than just a bunch of services—

A Community needs a kick-ass manager. Something that can keep it all straight: do the calls that need calling, delegate what needs delegating, and ultimately satisfy not the requirements of individual jobs, but the needs of the Community itself.

That is, it needs its own Concierge.

The “Arbiter” Concierge

I’m not here to argue the difference between Arbiter and Concierge: Zicklag himself mentioned the name “Arbiter” was not particularly well-suited, and we seemed to agree “Space Host” was unwise in a decentralized network. I had off-handedly suggested “Porter” as an alternative, but Concierge sounds a hundred times cooler (very important), and still centers service over judgement (also nice).

Which is to say, the Concierge is my flavor of the Arbiter…maybe. Or maybe it’s something different. Judgement is still open—all I ask right now is that you picture it as Charon from John Wick.

In my conception of the Concierge (“I need it to look like a distinguished, hypercompetent, and kinda-threatening, hot fictional man” aside) what matters most is that the Concierge is not the Community itself. It’s a Community delegate_: a service the Community has hired to handle matters on its behalf, neither part of it, nor inseparable.

To have the same credible exit as regular users, a Community must be able to continue existing without a Concierge—with degraded service if needed, but with all it needs to rebuild operations safely in its hands.

This means a Concierge’s role is not to hold the Community’s data or its credential. A Concierge may not hold the full set of keys, nor manage Members directly. It may not have read access—never mind write access to every record of the Community. But:

• It knows how and who to ask to satisfy the request being made
• It knows who is allowed to make that request
• It knows whether they have clearance to receive the response
• …and if it doesn’t know directly, it knows how to find out!

When a request comes in, the Concierge handles it by getting the right things done: reading data where it can, writing where it should, coordinating with other services (internal or external) where needed. And if:

1. The Concierge holds scoped, revocable permission to act on behalf of the Community and fullfil its needs and its Members’
2. Community data lives somewhere the Community owns
3. The job of Concierge can be easily reassigned to “whoever” comes next

then a Community can always walk away. It can fire its Concierge. The Community keeps existing across the swap; only the manager changes.

When a Concierge stops “sparking joy”, the Community elects a new one just like it did each time—through sign up, configuration, and continued usage. Give it access to the data, ask it to route requests appropriately, and let it take care of whatever needs to be done.

That is not to say electing a new Concierge is not a UX challenge—but so is a PDS. It may not be easy (to start!), it may be slightly confusing (to start!). But should a burning-enough happenstance light the laziness inertia off the ass of communities like mine, they’ll be clamoring to yeet their “signup-assigned Concierge”—to replace it with one more suited to their needs and, if necessary, principles.

And the promise of ATproto is that we’d let them.

There’s an App for That!

You may be squinting:

“You’re describing a service that holds a credential that the Community can authorize and revoke, which allows it to read and write Community data, and coordinate actions on the Community’s behalf. So you mean like…a Community App?”

Why not, let’s call it a Community App! Habitat already has a notion of installable apps that act on a Community’s behalf; so does OpenSocial, which I used to prototype atmosphere.community.

None of this is about whether the Concierge is something installable by the Community, or how it gets installed. The distinction is more subtle, and it’s best teased apart by looking at my experience with OpenSocial⁶, how today’s zero-generation ATproto-based Community Apps interface with random websites like atmosphere.community, and most importantly why they work that way.

AT-Communities: You(r Members) Have No Power Here

When a user logs into an ATmosphere service, they go through one of computing’s most sacred and accursed courtship rituals: OAuth—feared and revered (but mostly feared) by developers everywhere⁷. In this dance, a website or app presents itself at the door, fans out its requested scopes, and asks the User for permission to write data or take action on their behalf. The User may accept the proposal by logging in and tapping “Allow”, or leave the would-be suitor stranded at the redirect URI by cancelling the process⁸.

TODO: get a picture of the permission screen.

But while the dance is the same for every user and service, there is a fundamental distinction between a “User” logging in to a service, and a “Community Member” logging in to one:

• When a “User” logs into a service using their ATmosphere account, they may grant a service authorization to act on their own data—which may mean permission to update the User’s Bluesky profile, publish a leaflet on their behalf, or other cool things you can do with ATproto.
• When a “Community Member” logs into a service using their ATmosphere account, they may grant a service authorization to, well… act on their own data. But crucially a “Community Member” has no power to grant the service permission to act on the Community’s data itself—like writing shared content on the Community’s PDS, removing a rogue user from its list of Members, or removing themselves from it. After all, they don’t have that permission themselves!

This perfectly logical distinction creates a quite obvious, quite big problem for Communities on ATproto: only those who log in with the Community account itself can grant a service permission to act on the Community’s behalf⁹, but a Community account cannot be shared with every single Member.

To get around this limitation (and stop me if you’ve heard this before), there needs to be an intermediary program that the Community’s own account has pre-authorized, which can take action on behalf of the Community for valid requests—including those coming from Community Members.

That is the role of OpenSocial¹⁰.

Full page

1x 2x 4x

Expand figure

When a User wants to create a Community Account on ATproto, they:

1. Login to OpenSocial (or equivalent) as their Community Account-to-be
2. Grant OpenSocial permission to act on the Community Account’s behalf
3. “Write” into the Community Account’s PDS that their regular, everyday User Account is the Community Admin
4. Send Users to the Community’s OpenSocial Page, where they can login and ask OpenSocial to “write them” as Community Members

And they all lived happily ever after.

Now Featuring: “Third-party” Services

You may be wondering: does that make OpenSocial the Community’s Concierge, elected when the owner of the Community Account granted it power to act on the Community’s behalf?

As someone would say, “You’re Absolutely Correct!”—which is not wrong, but, as we all know, comes with asterisks and caveats.

Let’s poke and prod: what happens when a Community Member logs into another Service that’s not OpenSocial and takes an action that requires permission to modify Community Data?

• The Community Member cannot grant the Service permission to modify Community Data
• The Community Account could grant that Service permission if the Community Member had access to the Account
• But OpenSocial, like all good services, never sleeps¹¹ and is always ready and available for those who need to “piggyback” on its permissions

This is exactly how atmosphere.community works:

Full page

1x 2x 4x

Expand figure

Now, obviously, a new Service cannot just show up and ask to modify the Community’s data: the Community needs to authorize it first.

The way OpenSocial does this is the way most programs and most of the ecosystem does it:

1. A developer registers a third-party App
2. The App gets added to the Community, and receives its blessing¹² to interact with its data
3. That “Blessed App” is now allowed to write data and take actions on behalf of the Community.

…which is portable and works! Everyone has the power to create an App. The Community has total freedom to install new Apps, revoke App permissions, switch away from OpenSocial, or even pair it up with more services. OpenSocial even implemented App authentication via CIMD (a mechanism I loved discovering), which significantly lowered the friction for third-party App authentication!

So, in theory, all is good. The gods of decentralization smile upon us.

…or do they?

Blessed App Mode

That model never sat right with me, and I’m both very incensed about it, and full of doubts. Whenever I rant about this (and I have done at multiple points and multiple apps in the past), I always feel there’s something I’m missing: maybe it’s already possible and I’m not seeing it; maybe I’m being unreasonable about a problem that’s just plain impossible.

But, no matter how hard the technical problem of fixing it might be, there’s an issue I believe must be solved—if it hasn’t already been:

In Community App mode, the App is the unit the Community gives its trust to. The Community blesses specific Apps by installing them, and Blessed Apps get to write and act on its behalf.

So when a User with membership-granted permission to write Community data wants to use my random, no-one-heard-it-before, hyper-customized fuck-ass Astro website to add a record to the Community’s PDS, my fuck-ass Astro website’s options are:

1. Become a Blessed App by convincing someone with enough permission in the Community to install it—which is not gonna happen at scale
2. Go find an existing Blessed App that will let it piggyback on its credentials so it can take that specific action

Both of which are less than ideal, and both of which risk crushing the long-tail of small independent apps, websites, and utilities built for Members of Communities to interact with the Communities themselves—that is, all the fuck-ass Astro websites¹³ floating around in the ATmosphere.

Concierge Mode

In the mode I’m advocating for, which I’m calling “Concierge Mode”, Apps are not the only unit the Community gives its trust to.

In “Concierge Mode”, Apps have a standardized way to ask the Community (or *wink wink* a Community delegate) to trust the permissions of the entity the App is making requests on behalf of—whether it’s itself, a Member of the Community, or some random DID who asks to know or do something it may (or may not!) be authorized to, and thus may (or may not!) be allowed to do.

So, in Concierge Mode, my now-famous fuck-ass Astro website would:

1. Go to the Community’s Concierge
2. Present a signed request on behalf of the User (proof of origin and anti-tampering mechanism to be worked out), and ask the Concierge to act on it.
3. Wait for the Concierge to handle it according to the policy of the Community and to the User’s role in it: checking with whatever services it needs, writing data wherever it should be, acting on the Community’s behalf so the User’s request can either be acted upon or denied
4. Communicate the result back to the User

While it may seem simple, this flow is load-bearing: for the smaller Apps ecosystem to thrive, Services must be able to act on behalf of a Community Member with only the Member’s own credentials.

Because by piggybacking on the Member’s credentials, a fuck-ass Astro website doesn’t need to worry about whether it’s popular enough to end up installed, or whether anyone cares enough about it that they’ll pester a Community Admin to.

By piggybacking on the Member’s credentials, all a fuck-ass Astro website needs to do is bring the request to the Concierge, then go back to the User with the result—smile on its face, pepper in its walk, knowing it did the only thing it could: its best.

The Tyranny of Blessedness

You may be thinking:

Wait a minute— “Concierge Mode” is just the second option of “App Mode”: all fuck-ass Astro website did is “finding an existing Blessed App and piggybacking on its credentials”! Who cares if that App is the Concierge? Booo-oooh, give me my money time back!

And in a way… yes, “Concierge mode” does require Apps to piggyback on someone else’s credentials! After all, a Member just doesn’t have permission to write the Community’s data on its own. It cannot be manufactured out of thin air!

Full page

1x 2x 4x

Expand figure

But there’s a fundamental difference:

The difference is that the third-party Service and the Concierge don’t have to trust or know each other. The third-party Service is not vouching for the requester: it’s just passing along a signed request, and asking the Concierge to handle it. This means that the Community doesn’t need to go around trusting Apps one by one to grant them permission. And that makes all the difference.

Because the issue with the Community Apps system is not the idea that Blessed Apps exist: not only should they be part of this ecosystem, they will need to be. The issue is that, by making the barrier to offering smaller, complementary, additional services to Community Members that much higher, Blessed Apps’ lack of scalability creates the risk of a “plausibly-deniable lock in”—a much greater danger where they’re the blessed (🥁) or only option. It’s fundamental to the ecosystem that AT-Communities be interactable through more than just installable Apps or API keys.

For the ecosystem to thrive, Third-party Services (and fuck-ass Astro websites) must have somewhere to go—a front desk, or a loosely-defined “person”—and ask that their Users’ legitimate requests be fulfilled by someone that holds the authority to do so. By taking on this role, the Concierge centralizes trust to act on behalf of Community Members—and by doing so, it decentralizes the power to make those acts happen.

But wait, there’s Room Vault for More!

Until now we’ve mostly focused on point #1 in our list of must-haves for Concierge Swappability—which required learning a lot about how AT-Communities and permissions work. With this out of our way, time to quickly breeze through the rest¹⁴.

Next up:

So, where should a Community’s data live? Well, it depends¹⁵:

• For fully-public data that can be accessed by everyone, Community data can live on the Community PDS—exactly like it does for regular Users.
• For private Community data that can only be accessed by a specific slice of Users or Services, the accepted answer seems to be “Permissioned Spaces”.

…and that’s that! A Community can own all its data, QED. Next up, reassigning the Conc—

“Fully-private” Community Data

AH! Got you! As if I’d keep it that short¹⁶.

There’s one more type of Community data, often forgotten or shoehorned into the previous two: the “fully-private” Community data that no Community Member should freely and fully access at all—not the Admin, not the most trusted Mod, not anyone. This is all data that belongs to a Community, but that in many Communities almost no one (if anyone at all) can read or write directly and in its entirety—nor, for the most part, wants to.

It may include things like:

• Historical logs of moderation infractions
• Identity of Anonymous Posters
• PII of Community Members (or anything that could be used to identify them)
• Detailed access logs

…and many more. This category of data often varies from Community to Community. Sometimes, data a Community kept semi-public may become more (or less) sensitive as it changes and grows.

In the current ATproto world, where data is all either public or private, similar data often ends up stored within individual App(View)s. And while Permissioned Spaces will “bring some back into the light”, it won’t fully eliminate the need for it. After all, for every piece of data you bring, I can think of a Community that may want it to be private and not directly accessible to its Members.

“Objection!” A voice rises from the crowd. “What about membership? In every community someone needs to know who its members are!”

“Do they though?” I ask, with the smugness of one who wrote community software where no one knew who the Members were, except for the database¹⁷.

Made-up conversations where I win imaginary arguments aside, what I’m stressing here is the difference between:

• Information someone must have access to read and write in its entirety
• Information someone must be able to access smaller slices of, in very specific cases

“Some Community Member (or Service) needs to know” is not the same as “some Community Member (or Service) needs to read and write that data directly”. After all, in traditional software applications, not having a direct connection to the database doesn’t prevent people from asking questions about its data: they just go through a server—an intermediary that mediates their access. And incidentally, that mediation, self-hosted software shows us¹⁸, doesn’t have to mean that the data is not in the Community’s hands.

Because in the future AT-Communities world, unless a solution for Fully-Private Community Data is available, the need for this data won’t stop existing: it will just end up within individual Arbiters (or Concierges) instead.

Enter the Vault-verse

Let’s dive into our current predicament, then! How should Communities deal with their Fully-Private Data? Ideally, this data would be:

1. As much under their control as a PDS is
2. Not a PITA to use
3. Accessible to individual Users or Services according to their credentials, but with fine-grained access up to the individual record

…which is actually not that hard of a problem to solve! After all, ATproto developers already create stores of data that are not a PITA to use (problem #2) and can return fine-grained data to Users or Services (problem #3)—we just implement them over and over in every single AppView.

So let’s create one single data store! Even better: let’s put that single data store under a DID’s “control” exactly like we do with PDSes—which means we’re now also solving problem #1, in the same way we already know how.

I call this Community-owned Fully-Private data store “the Vault”.

Full page

1x 2x 4x

Expand figure

The Vault is a data store that:

• is available as a service named #atproto_vault under a DID, which keeps its content movable across hosts
• doesn’t provide direct write OR read access to anyone but the owner of the DID (if at all), which keeps its data private, only accessible through a Concierge
• can be queried through specific XRPC endpoints using Lexicons—almost like a PDS can be—but with granular permissions that can get down to the level of individual records

Once again, you can think of “the Vault” as the community’s own internal SQLite database, like the one many AppViews build: just a standardized one with no access rights directly granted, and a “Concierge”¹⁹ in front to mediate access. Data that AppViews currently hold internally can either be mirrored into the Vault or placed there to start—either way, the data travels with the DID, not with whoever’s running the AppView at the moment.

The Vault is where the off-protocol state goes so the AppView doesn’t have to hold it—a data store that “speaks” ATproto-language, but is not necessarily ATproto-shaped. Not today, at least.

New Concierge, Who Dis~?

And here we are, facing our final requirement:

How do we enable a community to choose a different concierge should their current one prove less trustworthy (or less featureful) than they’d like?

While this may seem like a hard question, its solution is already in front of us. And the journey we’ve been on until now has helped make it possible. After all:

1. The new Concierge can be granted credentials by the Community Account to do its job, which makes it again possible for third-party Apps to act on behalf of Community Members
2. The new Concierge can act on the same data as the previous one, including the private data in the Community’s Vault which removes the need to hold Community state in the Old Concierge Service itself

But there is one last issue, one we’ve until now overlooked…

New Concierge, Where It~?

The final hurdle: how does that random Service carrying the User request—our fuck-ass Astro website—know it should now go somewhere else to ask that it be fulfilled?

The same way it knows how to go find the Community’s PDS or the Community’s Vault: by looking up the #concierge service in the Community’s DID document.

Full page

1x 2x 4x

Expand figure

When a Community writes a Concierge into its DID document, it promotes the Concierge as an official part of the Community, even as it remains an external Service not directly run by it.

Then all third-party Services need is:

1. A standardized Lexicon to talk to Concierges (or other Services), even as implementations change
2. A standardized way for Concierges to forward requests to other Services whose endpoints they don’t directly implement, as chosen by the Community rather than by the requester

This second bit may seem more involved than what we have today, but honestly? Not by much.

After all, the PDS already has a standardized way to proxy requests to other services, just one that doesn’t let it do almost anything on its own. In a way, the PDS is already acting as a Concierge—it just abdicates the responsibility of knowing about a DID’s preferred services²⁰ and places it squarely on third parties.

What Makes a “User Account” a “Community Account”?

Once the Concierge is an official part of the Community DID, we get one final, crucial property: we can use the presence of a #concierge DID entry as the indication that the account is a Community account.

If this seems far-fetched… Well, it’s really not! Because this is exactly what ATproto does with labeler accounts today.

Once we do that, we have the pieces of the puzzle we need to:

1. Let its Members act according to their privileges and permissions
2. Let the Community itself own its own data
3. Identify and interact with a Community Account through ATproto, no matter who implements the endpoints that make it a Community

And through this we can achieve exactly what we asked for at the very beginning:

ATproto Communities can live on this protocol the way a user does—owning their identity, their data, and their freedom to fire any service that stops meeting their needs.

We just need to build it.

— Intermission: Members Management in Practice —

SO! This article took a long time to write…and there’s a whole other part below it (yes, again, I’m so sorry, I swear it’s worth it). I’m going to publish the rest in a few days, but I wanted to show how this might look in practice.

I’d probably need another day to polish it up where I want it to be, but as they say “¯\_(ツ)_/¯”. I’m not going to pretend I have all the answers. Still there’s A Vision™ here which I believe is roughly, directionally a correct shape to solve the issue—one that I’ve seen everyone involved hover around without exactly pinning down its parts.

Here are my examples, in both read and write editions, using the community.lexicon and com.atproto namespaces cause… well, I need some.

Have at it:

The Concierge — List Community Members Edition

Full page

1x 2x 4x

Expand figure

Here’s how it works, using the request to add a new Member to a community:

1. Some Requesting Entity (App, service, Member, member-asking-through-App, whatever) asks the Concierge to “community.lexicon.communities.listMembers”
2. The Concierge, consulting data it has access to (whether from the Vault, or from the DID document, or however else) determines this Community has elected a service that can answer community.lexicon.communities.listMembers on its behalf—maybe even the concierge itself!
3. The Concierge, having determined Requesting Entity is authorized by the Community to know that answers forwards it to the appropriate Responding Entity—or again, takes it on itself.
4. The Responding Entity, upon receiving community.lexicon.communities.listMembers, goes to whoever is in charge of the Vault (the #atproto_vault service) and asks for everything it needs to answer that question. For example: com.atproto.vault.listRecords(["community.lexicon.communities.member", "community.lexicon.communities.communityRoles", "community.lexicon.communities.rolePermissions"]).
5. The Vault’s manager returns the list of data the Responding Entity has access to—which may or may not be the full list of community.lexicon.communities.member records.
6. The Responding Entity sends it back to the Concierge
7. The Concierge sends it back to the Requesting Entity

…and that’s it! Simple, isn’t it?

Ok, that’s a lot of jumps…but that’s not the point! Jumps and paths can be optimized, shapes can be changed, and caches can be written. You know what they say: “Make it work, make it right, make it fast”.

The Concierge — Add Community Member Edition

Full page

1x 2x 4x

Expand figure

This is left as an exercise for readers. Or for me, after I haven’t gone to bed at 5AM for a week to write this article—not to mention, the whole rest of it.

Thanks for reading!

Sleight of Hand: It was Communities Users All Along! [Coming Soon]

TODO

Issue/Solution 1: (Anonymous) AskBox Vault [Coming Soon]

TODO

Issue/Solution 2: AskBox Concierge [Coming Soon]

TODO

It’s Not Over Yet (but I swear it’ll be soon): Enter Notifications [Coming Soon]

TODO

Let People Enjoy Solve Things [Coming Soon]

TODO

Epilogue: App-Centric Networks, User-Centric Networks [Coming Soon]

TODO