Skip to content
LiveShortly
Menu
‹

LiveShortly Pocket AI Integration

EndedOpen linkOn feedclaude-fable-5
@Rohit Sehgal· ended 10d ago· 41 events
@Rohit Sehgal
understand the pocket AI application, and the livershortly application as well. I would like to ship live server integration with the pocket AI application as well. Do some resaerch and create plan, In the pocket AI application we will have an integration which can allow a user to connect to the Liveshortly session and get this session in the pocket AI application as well.
… 15 earlier steps
› running Bash
› Bash ls ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit/Remote ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit/Peer; grep -n "SSE\|EventSource\|stream" ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit/Net/Net.swift | head
› running Bash
› Bash ls ~/rsehgal/github/getpocketai/PocketAI.Iphone/Sources/ | head -30
› editing Write
› Write ~/rsehgal/github/getpocketai/strategy/11-liveshortly-integration.md
◆ Claude

Research done, plan written: getpocketai/strategy/11-liveshortly-integration.md.

Key findings:

  • Two LiveShortly server flavors. Daemon mode (live daemon --server, /v1, bearer key) — pocket drives agent, already built both sides (old bak/pocket-ai client + daemon routes). Web platform (liveshortly-server, /api, OAuth) — pocket watches/joins streaming sessions. Request = web platform direction. Gap is Pocket side only.
  • Server needs zero changes. Device flow auth, session list, SSE stream with buffer replay + id-dedupe, comments, allow/deny decisions — all exist. live join CLI proves the client pattern.
  • New Pocket architecture has no LiveShortly code. But PocketKit already has SSEParser, Keychain hooks, Net egress ledger — reuse all three. No Rust / pocket-ffi changes (dodges L0 review).

Plan:

  1. Phase 1 — Swift-only PocketKit/LiveShortly/ module: device-flow auth (tokens in Keychain), typed REST client, AsyncStream SSE viewer. Fixture tests, no network.
  2. Phase 2 — iPhone UI: Settings integration (server URL + sign-in), sessions list under Devices tab, session viewer with event feed, comment composer, Allow/Deny banner on input_requested. Reconnect-on-foreground; no background SSE.
  3. Phase 3 (deferred) — fork/handoff from phone, push on permission prompts, Mac parity, public feed.

Open questions: Devices tab vs own tab; Pro-gated or free; default server URL.

Want this as a shareable page too — say so.

@Rohit Sehgal
The idea it to just have the integration with server, either lan or over some VPN mesh(responsibility of the owner) then perform the intrgationo inside the app(iphone and macboth) then works like normal. in that way create an integration plan detailed for the implemenation
… 5 earlier steps
› running Bash
› Bash grep -rn "purpose" ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit/Net/Net.swift | head; grep -rni "record_egress\|recordEgress" ~/rsehgal/github/getpocketai/PocketAI.Core/crates --include="*.rs" -l | head
› running Bash
› Bash grep -rn "NetPurpose" ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit --include="*.swift" -l | head -3; grep -rn -A 10 "enum NetPurpose" ~/rsehgal/github/getpocketai/PocketAI.Core/swift/Sources/PocketKit
› editing Write
› Write ~/rsehgal/github/getpocketai/strategy/11-liveshortly-integration.md
◆ Claude

Detailed implementation plan written: getpocketai/strategy/11-liveshortly-integration.md.

Shape:

  • Transport: app takes one base URL; LAN or VPN mesh is owner's job. HTTPS recommended; plain-HTTP LAN allowed via NSAllowsLocalNetworking, plain-HTTP over Tailscale rejected by ATS (copy tells user to use tailscale cert/HTTPS).
  • Zero server changes. Device-flow sign-in, sessions list, SSE stream, comments, allow/deny decisions — all existing liveshortly-server endpoints.
  • Swift-only module PocketKit/LiveShortly/ shared by iPhone + Mac. No pocket-ffi touch, no L0 review. All traffic through Net (new NetPurpose.liveShortly case — one line), so Network Proof stays honest; offline mode blocks it correctly. Reuses existing SSEParser and Keychain pattern.

9 task cards (repo card format, deps + done-when each):

  1. LSI-01 models + skeleton
  2. LSI-02 device-flow auth + token store (Keychain, refresh-on-401)
  3. LSI-03 REST client
  4. LSI-04 SSE stream (AsyncThrowingStream, dedupe by event id, reconnect with backoff)
  5. LSI-05 iPhone settings/connect (URL + test connection + sign-in)
  6. LSI-06 iPhone list + live viewer (event rows per 8 types, composer, Allow/Deny banner)
  7. LSI-07 Mac pane + viewer (shared row components via PocketUI)
  8. LSI-08 fixtures + contract tests (no-network swift test)
  9. LSI-09 QA e2e (local compose stack + Tailscale device run) + DECISIONS/BOARD entries

Order: 01→02→{03,04}→08→{05→06, 07}→09. Core module ~600–800 lines + tests.

Risks covered: ATS, SSE silence over VPN (60 s watchdog), mid-stream share revocation, token expiry on reconnect, big-session lazy render.

Open for you: Devices-tab entry vs own tab; Pro-gated or free; event rows in PocketUI (plan says yes).

@Rohit Sehgal
show me the plan document here
show me the plan here
plan show me here
Session ended — read only.