Skip to main content
Porch and Lantern are two small applications built on SharedGraph. They run on the hosted pilot at porch.sharedgraph.com and lantern.sharedgraph.com. They exist to show what can be built, not to be the application people settle into. Each is a client of a distinct registered application, and neither has privileged access. Both obey the same contract as any independent application: the same OAuth authorization, the same scopes, the same public and following reads, the same availability rules. What one of them can do, yours can do. Both run on the live pilot network. Posts, replies, likes and follows made there are real public records, visible through every application on the network.

​
What each application offers

Porch is an everyday client. It opens on the following feed, offers the public feed as a second view, and supports the complete basic social loop. Signed out it shows the public feed read-only. Lantern is a public explorer. Signed out it shows the public feed, threads and profiles, and names the originating application on every post. Signed in it adds replying, following, a following filter and reporting.

​
The scopes each one requests

Each application requests only the scopes its capabilities need, so the two consent screens differ visibly. Porch requests:
Lantern requests:
Lantern holds post:create for replies only, since a reply is a post with a parent. It never requests like:write, post:edit, post:delete or either inbox scope. See scopes for what each one permits.

​
Why Lantern omits likes, compose and an inbox

Lantern’s missing controls are deliberate. An application may omit a capability without removing or privatising the canonical record. A like made in Porch is a network record; Lantern simply offers no control for it and the like remains when the same post is opened there. The omission demonstrates two of the contract’s acceptance scenarios: follow in one application and see it in another, and like in one application while the other shows no like control. Adding likes or compose to Lantern would reverse a recorded decision, so they are not defects to report.

​
Walk through the cross-application scenarios

The sequence below takes about five minutes and leaves public posts on the pilot network.
  1. Open Lantern signed out. Read the public feed, open a thread and a profile, and note the originating application on each post. No account is needed for any of this.
  2. Create a pilot account at api.sharedgraph.com/signup. Choose a handle; it is fixed once chosen. Verify your email, then sign in.
  3. Open Porch and select Sign in. The consent screen names Porch and lists the scopes above. Approve it.
  4. In Porch, follow someone from the public feed, like one of their posts, and publish a root post of your own.
  5. Open Lantern and sign in. The consent screen names Lantern and lists a shorter scope set. The person you followed in Porch is already followed here, and the following filter shows them, with no second follow.
  6. Open the post you liked in Porch. Lantern shows no like control. Return to Porch: the like is still there. Nothing left the network; one application chose not to show it.
  7. Reply to your own root post from Lantern, then read the thread in Porch. The reply names Lantern as its originating application.
  8. Sign out of one application. The other stays signed in, because each authorization grant is yours to manage separately. Your account controls and network blocks live on api.sharedgraph.com/account, independent of either application.

​
The developer panel

Each application carries a collapsed For developers panel. It shows the application’s name, the scopes the current session actually holds, and a link to this documentation. Signed out it says so, since reading public posts needs no authorization grant. Sign in to see the scopes you granted, and compare the two panels to see the difference between the applications’ grants.

​
Build your own

The reference applications are built on the same server-backed boundary as the starter: a confidential client that keeps credentials and tokens on the server, validates the session before each protected view, and never retries an authorized refusal anonymously. Clone the starter repository, register your application with the scopes it needs, and begin from there.