Could a Solid pod hold your social graph and messages too? An unbuilt research question

Nothing here is built.

This page exists because the question is genuinely interesting and the answer is genuinely unsettled. It is not a roadmap, and treating it as one would be an invention.

The question

A pod stores resources over HTTP. A social graph is a set of relationships; a message is a small document. On the face of it, both are resources, so why not keep them in the pod, and let applications read them from there?

The proposal sketches exactly that: containers under your pod for social posts and for messaging material, with applications logging in against your identifier and reading what you permit.

Where it runs straight into something real

A pod is a request/response store. Messaging is a delivery problem.

Nobody's pod pushes anything. A message has to arrive, at a time the recipient is not asking, and a container that answers GET is not a delivery mechanism. Every serious design here ends up adding a component that is not a pod, and then the interesting question becomes what is left in the pod at all.

And there is a specific, concrete blocker on our side. The pattern that makes an inbox work is append, letting a stranger add to a container without reading what is already in it. Our interface exposes two of the four permission modes, and append is not one of them. We could not express "you may drop a message here but not read the others" through anything we have built, and that is not a detail, it is the shape of the whole feature.

The other three hard parts, named rather than waved at

• Key custody for end-to-end encryption. Storing room keys in a pod means the pod's access control is now protecting your message history. Its enforcement is real and its granularity is ours to fix.
• Read paths for other people's servers. A follower on another system has to be able to resolve your identifier and fetch what you published, and generic tooling does not resolve ours.
• Access control per relationship. A follower graph needs rules per person or per group, at a volume nobody manages by hand.

None of these is unsolvable. All of them are unsolved here.

One idea in the proposal that this surface may not claim

The proposal imagines proving follower relationships without revealing identities.

So it is described here as a research idea and nothing else. A reader who takes it as a capability has been misled, and we would rather draw the line than let the sentence do its own work.

What DOES exist, with the scope attached

A messaging capability is live in this estate, on a different product.

Asking relay.solidus.network for an invitation returns a real out-of-band invitation document. An invented path on the same host returns a route-not-found error, so the endpoint is real rather than a catch-all.

That surface is self-labelled BETA, it is not pod, and no integration between the two exists. Naming it here without those three qualifications would be exactly the borrowing this estate keeps catching itself doing.

What the honest answer is

Yes, a pod can hold this data. No, that does not make a messaging system, and the parts that are missing are the parts that are hard.

If it is ever built, the interesting result would be negative as easily as positive, that the pod turns out to be the wrong home for real-time material, and the right home only for what you want to keep. We do not know, and we would publish it either way.