Sensemaking Scenius Community Application — Brainstorming

Goal: Agreement on what to build and why; actionable next steps to collaborate; a basic MVP scope that addresses core Sensemaking Scenius community needs

Context

Sensemaking Scenius is a community exploring collective intelligence and relational technology. Two collaborators are looking to combine their tools into a shared community application.

Gabriel’s projects: (1) Portico — a spatial community platform (SvelteKit, Jazz CRDT, LiveKit proximity voice) where members navigate rooms as energy balls on a shared canvas; (2) Knowledge Graph Builder — a Python pipeline extracting Telegram conversations into a semantic knowledge graph using the SIOC ontology and Oxigraph.

Artem’s projects: (1) My Community — a Chrome extension replacing the new tab with a community dashboard aggregating links, Bluesky posts, and participation events from Telegram, Slack, Luma, and Navidrome Jam rooms; (2) Navidrome Jam — a synchronized music listening app on top of self-hosted Navidrome, enabling shared queues and real-time playback via Socket.io.

The question is how these four tools intersect to serve the Sensemaking Scenius community’s core needs.

Summary

Sensemaking Scenius Community Application — Strategic Summary

🎯 Core Vision

A shared digital space where the Sensemaking Scenius community’s knowledge accumulates visibly, participation has a low floor, and members can stay connected without needing to be everywhere at once.

The fundamental problem being solved: fragmentation. Conversations, decisions, and knowledge are scattered across Telegram, Zoom calls, Notion, and individual projects with no unified memory or ambient awareness layer.

💡 Key Insights & Breakthroughs

The Real Problem Isn’t Just Information Overload

It’s that curation has no surface to curate into. People don’t organize knowledge because there’s nowhere to organize it that others will see. The technical infrastructure enables the social behavior, not the other way around.

Three-Layer Filtering Architecture

Instead of trying to solve everything with AI or manual curation:

1. Automated baseline: Extract links, topics, activity (what happened)
2. Social signals: Member reactions, engagement (what matters)
3. Structured synthesis: Harmonica sessions for decisions (what we think)

Critical distinction: Be confident about facts, cautious about meaning. Automate the former, structure the latter with human input.

The Knowledge Graph as Intelligence Layer, Not Backbone

The KG doesn’t need to be production-ready for MVP. Direct Telegram integration provides the plumbing; the KG adds semantic intelligence later. This prevents the entire project from being blocked by KG hosting/reliability concerns.

Read-Only Portico Isn’t Enough

Just displaying Telegram in a prettier interface doesn’t justify a new tool. The value is spatial presence + voice + context summaries together. But without write-back to Telegram, it fragments the community rather than unifying it. Bidirectional sync (or at minimum, voice conversation summaries posted back to Telegram) is essential.

🏗️ MVP Scope (4-6 Weeks)

What We’re Building

1. Portico with Telegram-Linked Rooms

• 3-5 rooms mapped to existing Telegram subgroups (Workshop, General, Projects)
• Spatial UI with energy ball avatars, proximity voice
• Recent messages from linked Telegram channels displayed in rooms
• Bidirectional sync via Telethon: messages flow both ways (critical path item)
• Fallback: read-only + voice conversation summaries posted to Telegram if full sync proves fragile

2. Daily Channel Summaries

• LLM-generated narrative summaries per active channel (3-5 sentences, not keywords)
• Example quality bar: “Gabriel proposed linking Portico rooms to Telegram subgroups. Jon offered an existing Telethon implementation. Open question: should rooms be fixed or emerge dynamically?”
• Displayed in Portico room context panels and My Community dashboard
• Pipeline: scenius-digest → LLM call → REST API

3. My Community Integration

• Chrome extension new tab shows:
  • Active Portico rooms (who’s in them)
  • Weekly link digest (already working)
  • Daily channel summaries
• AT Proto auth with Scenius whitelist
• Entry point: “Open a tab and see what’s happening”

4. Navidrome Jam Presence

• Already integrated, shows live listening rooms
• Provides ambient life signal even during quiet conversation periods

What’s Explicitly Out of Scope

• Full Knowledge Graph Builder integration
• Emergent/dynamic rooms (start with fixed rooms)
• Cross-community interoperability via SIOC
• Member reaction signals on links (social filtering layer)
• Public website gateway
• Mobile optimization

🔧 Technical Architecture

Shared Data Layer

Knowledge Graph Builder (when ready) exposes REST API endpoints backed by SPARQL queries. Any tool can query independently rather than tight coupling. Uses SIOC ontology for future cross-community interoperability.

API Contract (Must Define Week 0)

GET /channels/{id}/summary
Returns: {
  channel_name,
  period,
  summary_text,
  message_count,
  active_members,
  topics[]
}

Auth Decision Needed

• My Community uses AT Proto whitelist
• Does Portico share this auth or use separate login?
• Decision: Accept two logins for MVP, unify later OR share auth layer now

Integration Points

• Portico ↔ Telegram: Telethon bridge (Jon has working implementation)
• My Community ↔ Portico: Shared summary API + room presence data
• scenius-digest ↔ Everything: Base data extraction layer

👥 Division of Labor

Gabriel Owns

• Portico rooms (spatial UI, voice, Jazz CRDT sync)
• Telethon bridge (critical path)
• Push repo to GitHub (action item)

Artem Owns

• LLM summarization pipeline (scenius-digest + Claude/OpenAI → REST endpoint)
• My Community integration (dashboard, AT Proto auth, whitelist)
• Maintain scenius-digest API and Navidrome Jam feed

Shared Responsibilities

• Week 1: Agree on API contract
• Week 2: Spike integration with real data
• Weeks 3-4: Build in parallel
• Week 5: Integration + testing with 2-3 community members
• Week 6: Launch to full Scenius group

People to Involve

• Jon: Telethon auth implementation, compute cluster access, early tester (Week 1)
• Kristen: Early tester for non-technical perspective (Week 5)
• Don’t involve more people until something works — feedback on broken prototypes is counterproductive

⚠️ Critical Risks & Mitigations

1. Telethon Bridge Complexity (HIGHEST RISK)

Risk: Telegram API auth is finicky. Message sync could be unreliable, causing lost/duplicated messages and destroying trust.

Mitigation:

• Jon’s existing implementation reduces risk
• If bidirectional proves too fragile: fall back to read-only + bot-posted voice summaries
• If blocked >1 week: use Telegram bot for read-only room feeds
• Must have at least basic write-back (text messages via bot) within 2 weeks post-launch

2. Summary Quality

Risk: LLM summaries are generic/inaccurate, people stop reading them.

Mitigation:

• Start with strong prompt
• Manually review first week of outputs
• Iterate before running unsupervised
• Quality bar: 70% context from summary, scan key messages for rest

3. Scope Creep

Risk: Building emergent rooms, KG integration, cross-community features during MVP.

Mitigation:

• Fixed rooms only
• Daily summaries only
• Dashboard only
• If either person starts KG integration in Week 3 → red flag

4. Community Expectations

Risk: Announce too early → people try half-built tool → bad experience → don’t return.

Mitigation:

• Brief async updates in Workshop Telegram every 2 weeks (screenshot + short message)
• Show messy progress, don’t go dark for 6 weeks
• Soft launch with 3-4 testers first
• Full group invite only when solid

5. Timeline Slippage

Risk: One component blocks the other.

Mitigation:

• Components aren’t blocked if API contract defined Week 1
• Spike integration Week 2 with dummy data catches misalignment early
• If timeline slips: drop LLM summaries from MVP, ship Portico + My Community with raw feeds
• Don’t add developers — scope reduction is faster than onboarding

6. Quiet Weeks Problem

Risk: Dashboard shows “0 active rooms, 1 link” → communicates stagnation.

Mitigation:

• Longer time horizons: show “recent” with rolling window, not “this week”
• Navidrome Jam shows presence even without substantive discussion
• Avoid vanity counters (don’t show “3 messages this week”)
• Honest feedback: if dashboard feels empty, maybe community needs that signal

📊 Success Criteria

Technical Success

• Portico rooms display Telegram messages reliably
• Messages sent from Portico appear in Telegram (or voice summaries do)
• Daily summaries provide 70%+ context without reading full threads
• My Community dashboard loads active rooms + summaries on new tab
• 3-4 testers can navigate the system without explanation

Social Success

The real test: After 3 months, do members other than Gabriel and Artem create rooms and respond to suggestions without prompting?

If it’s still just the two builders maintaining everything, we’ve built infrastructure, not a community tool.

User Experience Success

A member opens their browser. Their new tab shows Sensemaking Scenius — not as a chat app, but as a living map of what the community is thinking about right now. They see:

• A few active rooms with people in them
• A digest of interesting links from the past week
• A quiet music stream they can join
• Room summaries that orient them without reading 40 messages

They click into a room, see what’s been discussed, and either join voice or leave an async message. Their participation — even just a thumbs up — makes the shared memory richer. They come back because every time they open that tab, there’s something new to learn or someone to connect with.

🚀 Next Actions

Week 0 (Before Building Starts)

1. Define API contract (Gabriel + Artem)
2. Decide auth model (shared vs. separate)
3. Pick 3-5 Telegram channels to link as rooms (based on actual activity)
4. Gabriel: Push Portico repo to GitHub

Week 1

• Implement API contract on both sides
• Jon: Integrate Telethon auth implementation
• First coordination update in Workshop Telegram

Week 2

• Spike integration with real data (even if UI is rough)
• Iterate on LLM summary prompts based on actual channel data
• Identify any misaligned assumptions early

Resources Needed

• LLM API costs: ~$1-2/month (Claude Haiku or GPT-4o-mini)
• Hosting: Gabriel’s free server + Jon’s cluster as backup; My Community on Vercel; Portico needs Railway or Jon’s cluster
• Shared coordination channel: existing Scenius Workshop Telegram group

🎯 Strategic Alignment with Community Needs

Addresses Core Pain Points

Information & Communication

• ✅ Summaries provide high-level view without reading everything
• ✅ Spatial rooms + context panels make relevant info discoverable
• ✅ Link digest surfaces signal from noise

Coordination & Decision-Making

• ✅ Harmonica session outputs become visible artifacts in shared memory
• ✅ Lower activation energy: see what’s happening from new tab, join with one click
• ⚠️ Doesn’t directly solve accountability/follow-through (future iteration)

Structure & Roles

• ⚠️ Doesn’t create formal processes (out of scope)
• ✅ Makes activity visible so members can self-organize around what’s happening

Knowledge & Memory

• ✅ Shared memory accumulates visibly
• ✅ Links and discussions connected by context, not just chronology
• ✅ Queryable via KG (future), browsable via rooms and summaries (MVP)

Aligns with Telegram Restructuring Proposal

• Main room → General Chat
• Interest subgroups → Portico rooms
• Sensemaking Drip → Dashboard digest feed
• Rooms provide digital spaces to hang out beyond just reading messages

💭 Open Questions

1. Auth model: Shared AT Proto across both tools or accept two logins for MVP?
2. Which specific 3-5 Telegram channels become rooms? (Needs community input)
3. Summary cadence: Daily per channel, or adaptive based on activity?
4. Voice conversation summaries: Auto-generated or manually posted by participants?

🌟 Long-Term Vision (Post-MVP)

• Knowledge Graph Builder as full intelligence layer
• Emergent rooms based on cross-cutting themes
• Member reaction signals for social filtering
• Cross-community interoperability via SIOC ontology
• Public website as gateway for new members
• Mobile-optimized experience
• Structured Harmonica sessions (2-3/month) feeding directly into shared memory

The key insight: Build the minimum surface where knowledge can accumulate, then let the community’s existing social behaviors fill it in. The tool enables curation as a byproduct of normal participation, not as unpaid labor.

Participant Responses

Participant 1

User shared the following context:

The biggest frustration is fragmentation. Conversations happen across Telegram, calls, shared docs, and individual projects — but there’s no single place where the community’s knowledge accumulates. You have to “be there” to know what happened. If you miss a week, you’re lost.

Specific pain points:

• Discovery is broken. Interesting links, ideas, and references get shared in Telegram and disappear into scroll. There’s no way to search or browse what the community has collectively surfaced.
• Projects are invisible to each other. Gabriel is building Portico, I’m building My Community and Navidrome Jam — but we only learned about overlaps through live calls. There’s no ambient awareness of what others are working on or where they need help.
• Participation has a high floor. To contribute meaningfully you need to attend sync calls or read long Telegram threads. There’s no lightweight async way to participate — something between “lurking” and “showing up to every call.”
• No shared memory. The community generates insights, makes informal decisions, surfaces patterns — but none of it is captured in a way that’s browsable or buildable-upon. Every conversation starts from scratch.

What members wish existed: a low-effort way to stay in the loop, see what others are thinking and building, and contribute without needing to be online at the same time.

Both, but the technical problem enables the social one. People don’t curate because there’s no place to curate into. If you had a shared surface that passively accumulated community activity, the social norm of “tagging what matters” could emerge. Without the surface, curation feels like unpaid labor with no audience.

On who does the work — I think it has to be layered:

1. Automated baseline. Extract links, topics, and activity from existing channels (Telegram, calls) without anyone lifting a finger. Gabriel’s Knowledge Graph Builder does this for conversation structure. My Community’s digest API does it for links. Neither is sufficient alone but together they cover a lot.
2. Lightweight member input. Not full curation — more like reactions. Upvote a link, flag something as important, tag a project. The kind of thing you can do in 5 seconds from a phone.
3. AI-assisted synthesis. Periodic summaries of what the community discussed, decided, or disagreed on. This is where Harmonica-style structured conversations could feed back — session outputs become part of the shared memory automatically.

The key insight: curation shouldn’t be a role or a task. It should be a byproduct of normal participation. If sharing a link in Telegram automatically surfaces it in the community dashboard, that’s zero-effort curation.

To your question about shared memory — it’s primarily technical. The social will exists. People reference past conversations all the time (“remember when we discussed X?”). They just can’t find them. An indexed, linked knowledge layer would unlock the social behavior that’s already latent.

Fair point — “ingest everything” is just building a second firehose. The filtering mechanism matters more than the ingestion.

I think the answer is social filtering with algorithmic support, not pure automation:

For links and content: The scenius-digest system already does basic filtering — it only surfaces links shared in community channels, not every message. But that’s still too much. The next layer is member signals: if 3 people react to a link, it’s signal. If nobody engages, it fades. This is closer to how Hacker News works than how a search engine works — human attention as the primary filter, with recency decay for everything else.

For the AI synthesis problem: You’re right that automated “decision extraction” is dangerous — it can manufacture consensus that didn’t exist. The safeguard is that Harmonica sessions produce structured outputs with participant validation. The summary isn’t an AI’s interpretation of a chaotic Telegram thread — it’s a synthesis of responses that participants gave to specific questions in a structured format. That’s a fundamentally different input quality. The risk drops when the source material is already structured.

For unstructured conversations (Telegram, calls) — I’d argue we should NOT auto-extract decisions. Instead, the system should surface that a conversation happened and what topics it touched, then let members decide if it’s worth a structured follow-up. The Knowledge Graph Builder maps topics and connections, not conclusions.

So the filtering stack is:

• Automated: topic extraction, link deduplication, activity detection (what happened)
• Social: member reactions, engagement signals (what matters)
• Structured: Harmonica sessions for things that need actual synthesis (what we think)

The distinction is important: the shared memory should be confident about what happened (facts, links, activity) and cautious about what it means (synthesis, decisions). The former can be automated. The latter needs human structure.

You’re right that if only 3 people signal, the filter reflects 3 people’s interests, not the community’s. But I’d argue that’s actually fine for a community this size. Sensemaking Scenius is ~15-20 active members. You don’t need representative sampling — you need any signal above zero. Right now the filtering mechanism is literally nothing. Going from zero signals to even a few engaged curators is a massive improvement.

And the participation burden is categorically different. “Attend a 90-minute call at a specific time” vs. “tap a thumbs up on a link while scrolling your phone” — these aren’t on the same spectrum. The floor for reacting is so low it barely counts as participation. The people who lurk in Telegram already see the links — we’re just asking them to tap once if something resonated. Some won’t, and that’s fine.

The real risk isn’t uneven engagement — it’s cold start. If the dashboard launches with no signals and no activity, nobody develops the habit. The solution is launching with the automated layer already populated (digest links, recent topics, project activity) so the feed is useful on day one even with zero member input. Social signals then refine what’s already there rather than creating it from scratch.

On session frequency: I’d expect structured Harmonica sessions to be event-driven, not scheduled. Run one when there’s a genuine question to resolve — “what should we build together?”, “how did our experiment go?”, “where do we invest next quarter?” Maybe 2-3 per month. The synthesis layer stays thin but high-value — each session produces a meaningful artifact rather than routine noise.

The bigger insight is that the three layers have different cadences: automated runs continuously, social signals accumulate passively, structured sessions happen when needed. They don’t all require the same engagement frequency. A member who never reacts to links but shows up for one Harmonica session per month is still contributing to the shared memory.

The most promising intersection came up clearly in yesterday’s workshop: Knowledge Graph Builder as the shared data backbone, with REST API endpoints that any tool can query.

Gabriel’s plan is to host the KG on a cloud server and expose REST endpoints backed by SPARQL queries. This is the key architectural decision — instead of tightly coupling tools, we build a shared data layer that Portico, My Community, Harmonica, or even Telegram bots can all query independently. As I said on the call: “We build the pipeline using the knowledge graph and then we can use that in different ways — for Portico, to inform Harmonica sessions, as Telegram bots in subgroups, or as a Chrome extension.”

Portico rooms mapped to Telegram subgroups is the most concrete integration. Gabriel proposed that each Portico room corresponds to a Telegram group, with a sidebar showing recent activity from that group. You don’t need to be in the Telegram group to see a summary of what’s happening — just enter the room in Portico. Text messages from Portico could sync back to Telegram via Telethon (Jon already has a working implementation for the auth piece).

What excited me most was the emergent rooms idea. Beyond mirroring the fixed Telegram structure, rooms could emerge dynamically based on what the community is actually talking about. The Knowledge Graph would surface recurring cross-community themes — “here’s what people are discussing most frequently, maybe you should create a room about it.” Gabriel saw the same hybrid: fixed rooms for existing structure, plus anyone can spin up a room around an emerging topic.

My Community as the authenticated entry point. I proposed integrating Portico into the Chrome extension — you sign in with your AT Proto handle, and if you’re on the Sensemaking Scenius whitelist, you get access to the community layer directly from your new tab. The digest data could also flow into Portico as a side panel, so the dashboard content and the spatial experience share the same information.

Trade-offs of combining vs. keeping separate:

• Gabriel is building in SvelteKit with Jazz CRDTs. I’m building in Preact with Vite. Forcing a single app means one stack wins and the other rewrites. The REST API approach avoids this — tools stay independent but share data.
• The SIOC ontology Gabriel is using (Semantically Interlinked Online Communities) makes this extensible. Other communities using the same ontology become interoperable — Open Civics, potentially Metagov via Slack bots. Cross-community collaboration becomes possible without merging codebases.
• The risk is the cold start Gabriel flagged on hosting — he’s using a free cloud server for now. Jon offered compute cluster access as a more stable option.

On the KG reliability risk — you’re right to flag it, but I think the framing is slightly off. The Knowledge Graph doesn’t need to be the backbone for the MVP. It’s the intelligence layer, not the plumbing.

The fallback is already built: My Community’s digest API works today without the KG. It pulls links and activity directly from Telegram via scenius-digest. Portico can display room activity from Telegram directly via Telethon without needing the KG at all. The MVP works with just direct Telegram integration — rooms show messages, the dashboard shows links. No KG required.

The Knowledge Graph adds a quality upgrade — topic clustering, semantic connections, cross-community links — but the basic integration functions without it. So the 4-6 week timeline shouldn’t depend on the KG being production-ready. We build the direct integrations first, then layer the KG on top when Gabriel has stable endpoints. If the free server dies, we lose the smart features but the basic tools still work.

That said, Jon’s compute cluster isn’t really a “third party dependency” in the concerning sense — Jon is a community member offering shared infrastructure to the group. It’s the same model as someone hosting a shared Telegram bot. The risk is real but it’s a community coordination risk, not a vendor lock-in risk.

On emergent rooms and thresholds — I think for our community size, automated thresholds would be premature. With 15-20 members, you might get 2-3 cross-cutting themes at any given time. The Knowledge Graph can surface “these topics are coming up across multiple channels” as suggestions, but the actual room creation should be manual — someone sees the suggestion and decides to open a room. Think of it as the KG providing prompts, not making decisions.

If we wanted to automate later at larger scale, it would probably be something like: topic appears in 3+ different channels within a week, mentioned by 3+ different people, and doesn’t map to an existing room. But honestly, for a community this size, “Gabriel or I notice a recurring theme and create a room” is a perfectly fine mechanism. Don’t over-engineer the social layer.

You’re right to call that out. If the MVP is just “Telegram messages displayed in a Portico room and links displayed in a dashboard,” we’ve built a nicer window into the same fragmented information. The scroll problem moves but doesn’t go away.

The minimum intelligence layer the MVP actually needs isn’t the full Knowledge Graph — it’s topic grouping and temporal context. Specifically:

1. Links grouped by conversation context, not just chronologically. “These 3 links were shared during a discussion about decentralized identity” is qualitatively different from “here are today’s links.” The scenius-digest API already captures when and where links were shared. Adding even basic topic tags (extracted from surrounding messages) turns the flat list into browsable knowledge.
2. Activity summaries per room/channel. Not full semantic analysis — just “this week in the workshop channel: 12 messages from 4 people, main topics were Portico integration and KG hosting.” This is achievable with simple keyword extraction, no graph database required.
3. Session artifacts as anchors. When a Harmonica session produces a summary, it becomes a reference point — a thing you can link to and build on. This is already built into the platform. The MVP should make these visible in the dashboard alongside the organic Telegram activity.

So the honest answer: direct Telegram integration alone doesn’t solve the core problem. But the minimum viable intelligence is closer to “basic NLP topic extraction” than “full semantic knowledge graph.” The KG is the long-term vision. The MVP needs something in between — smarter than raw feeds, simpler than a triple store.

On the maintainer question — yes, right now Gabriel and I would be the primary people acting on suggestions. That’s fine for launch. But you’re pointing at something real: the system needs to develop a norm where creating a room or flagging an important topic is something any member does, not just the builders. The way to seed that is making the action trivially easy and visibly rewarding — you create a room, people show up, the room has context from the KG. The tool’s usefulness is what drives adoption of the norm, not the other way around.

But I’ll be honest: if after 3 months it’s still just us two maintaining everything, we’ve built infrastructure, not a community tool. The test is whether other members start creating rooms and responding to suggestions without being prompted.

You open your browser and your new tab shows you Sensemaking Scenius — not as a chat app or a feed, but as a living map of what the community is thinking about right now. There are a few active rooms where people are talking (one about decentralized identity, one about an upcoming event), a digest of the most interesting links and ideas from the past week surfaced by member engagement, and a quiet music stream you can join if you want to feel connected while you work. You click into the decentralized identity room — you can see a summary of what’s been discussed, browse the relevant links, and either drop into voice with the two people already there or leave an async message. You don’t need to have been in every Telegram thread to know what’s happening. The community’s knowledge is accumulating visibly, and your participation — even just a thumbs up on a link — makes it richer. You come back because every time you open that tab, there’s something new to learn, someone to connect with, or a conversation you can meaningfully join without needing a 30-minute catch-up.

On summary quality — you’re right that “12 messages, topics: identity, protocols” doesn’t solve the catch-up problem. That’s a notification, not context. The minimum useful summary is something like: “Gabriel proposed linking Portico rooms to Telegram subgroups. Jon offered an existing Telethon implementation for the auth layer. Open question: should rooms be fixed or emerge dynamically from topics?” That’s a 3-sentence narrative, not keyword extraction.

Can we get there without the full KG? Probably, yes. An LLM call on the last N messages in a channel can produce a decent narrative summary. It doesn’t require semantic triples or graph queries — it requires a language model and a prompt. The scenius-digest pipeline already processes Telegram messages. Adding a summarization step per channel per day is achievable in the MVP scope. It won’t be as good as a knowledge-graph-informed summary that draws on historical context, but it clears the bar of “can I understand what’s happening without reading 40 messages.”

The honest answer on quality: the summaries need to be good enough that you trust them to orient you, not good enough to replace reading the thread. If the summary gets you 70% of the context and you can scan the key messages for the rest, that’s the right level. Perfectionism here would block the MVP.

On quiet weeks — this is a real design problem and I don’t want to hand-wave it. A community of 15-20 people will have quiet stretches. If the dashboard shows “0 active rooms, 1 link this week,” it communicates stagnation regardless of whether the community is actually healthy.

A few approaches:

• Longer time horizons. Instead of “this week” as the default, show “recent” with a rolling window that expands during quiet periods. Show the last 10 interesting things regardless of when they happened.
• The music stream helps here. Navidrome Jam rooms show “2 people listening right now” even when nobody’s discussing anything substantive. That’s ambient life — the community exists, people are present.
• Avoid vanity counters. Don’t show “3 messages this week.” Show the rooms, the topics, the links — without quantities that invite comparison to busier weeks.

But honestly, if the dashboard feels empty, that might be honest feedback the community needs. A quiet dashboard could prompt someone to start a conversation or share a link. The worst outcome isn’t “the map looks quiet” — it’s “the map looks busy with artificial content that nobody cares about.”

In the MVP (4-6 weeks):

1. Portico with Telegram-linked rooms. 3-5 rooms mapped to existing Telegram subgroups. Enter a room, see recent messages, join voice or leave text. Bidirectional sync via Telethon so messages flow both ways. This is Gabriel’s core build.
2. Daily channel summaries. An LLM-generated narrative summary per active channel, updated daily. “Here’s what happened in the workshop channel today” — 3-5 sentences, not keywords. Displayed as the room’s context panel in Portico and in the My Community dashboard. Pipeline: scenius-digest pulls messages, an LLM call summarizes, result stored and served via API.
3. My Community integration. The Chrome extension new tab shows: active Portico rooms (who’s in them), the weekly link digest (already working), and the daily summaries. AT Proto auth with a Scenius whitelist for access. This is the “open a tab and see what’s happening” experience.
4. Navidrome Jam presence. Already integrated into My Community — shows live jam rooms in the feed. No new work, just keep it working.

What can wait:

• Knowledge Graph Builder integration (the full semantic layer — useful but not required for launch)
• Emergent/dynamic rooms (start with fixed rooms, add dynamic creation later)
• Cross-community interoperability via SIOC (important vision, but nobody else is using the ontology yet)
• Member reaction signals on links (the social filtering layer — the digest works without it for now)
• Website as public gateway (focus on the authenticated member experience first)
• Mobile optimization

Biggest risk to this scope:

The Portico-Telegram bidirectional sync. It’s the technical centerpiece, and it depends on Telethon auth, message formatting across platforms, and handling edge cases (edits, replies, media). Jon has a working implementation for parts of this, but integrating it into Portico is untested. If the bridge is unreliable, messages get lost or duplicated, and trust in the tool drops immediately.

The mitigation is making the bridge read-only for the MVP if bidirectional proves too fragile — Portico shows Telegram messages but doesn’t write back. That’s still useful as an ambient awareness tool. Bidirectional sync becomes a fast follow.

Second risk: the daily summaries being low quality. If the LLM produces generic or inaccurate summaries, people stop reading them. Mitigation: start with a good prompt, manually review the first week of outputs, iterate before trusting it to run unsupervised.

On read-only Portico — you’re right that just displaying Telegram messages in a different interface doesn’t justify a new tool. But the value proposition of read-only Portico isn’t “read Telegram somewhere else.” It’s spatial presence + voice + context summaries alongside the messages. You can see who else from the community is online, walk into a room, and start talking about what’s being discussed in the Telegram channel — with a summary right there so you don’t need to scroll back. That’s a fundamentally different experience from opening Telegram.

The fragmentation risk is real though. If 3 people discuss something in Portico voice and it never reaches Telegram, the Telegram-only members miss it. The mitigation for this specific case: even without full bidirectional sync, we can post a summary or notification to Telegram when a voice conversation happens in a linked room — “3 people talked in the Workshop room for 20 minutes, here’s what was discussed.” That’s a lighter integration than full message sync and addresses the worst fragmentation scenario.

But I’ll concede the point: if we can’t get any write-back to Telegram working, Portico becomes a nice overlay rather than a unifying tool. Read-only is a viable fallback for launch week, not for the full MVP period. We should commit to at least basic write-back (text messages from Portico posted to Telegram via bot) within the first 2 weeks post-launch.

On division of labor and timeline risk:

• Gabriel owns: Portico (rooms, spatial UI, voice, Jazz CRDT sync) and the Telethon bridge. This is the critical path.
• I own: My Community integration (dashboard, AT Proto auth, whitelist), the LLM summarization pipeline, and the scenius-digest API as the data layer.
• Shared dependency: the API contract between the summarization pipeline and Portico’s context panel. We need to agree on endpoints and data format in week 1.

If Gabriel’s component slips, we still launch My Community with daily summaries and the link digest — that’s useful on its own as the “open a tab and see what’s happening” experience, just without the spatial layer. If my component slips, Gabriel launches Portico with Telegram integration but without summaries or the Chrome extension entry point.

The key insight: neither component is blocked by the other if we agree on the API contract early. The summarization API serves both Portico and My Community. As long as that interface is defined in week 1, we can build in parallel and integrate in weeks 5-6.

The real timeline risk isn’t one component slipping — it’s integration week revealing that our assumptions about data format or auth don’t align. Front-loading the API contract and doing a spike integration in week 2 (even with dummy data) would catch that early.

Decisions before building starts (week 0):

1. API contract between summarization pipeline and Portico/My Community. What does the summary endpoint return? Proposed: GET /channels/{id}/summary returning {channel_name, period, summary_text, message_count, active_members, topics[]}. Gabriel and I need to agree on this before writing any integration code.
2. Auth model. AT Proto whitelist in My Community is straightforward, but does Portico use the same auth? Or separate? If separate, members sign in twice. Decision: either share an auth layer or accept two logins for now and unify later.
3. Which 3-5 Telegram channels to link as rooms. We have subgroups — Workshop, General, maybe Projects. Pick the ones with actual activity. Don’t create rooms for dead channels.

Division of labor:

Gabriel:

• Portico rooms with spatial UI, voice proximity, text chat (his existing codebase)
• Telethon bridge: Telegram messages displayed in Portico rooms, write-back via bot
• Push repo to GitHub (action item from yesterday’s call)

Me:

• LLM summarization pipeline: daily per-channel summaries via scenius-digest + Claude/OpenAI API call, stored and served via REST endpoint
• My Community integration: active rooms widget, daily summaries in the dashboard, AT Proto whitelist auth
• Maintain scenius-digest API and Navidrome Jam presence feed

Shared:

• Week 1: agree on API contract, both build against it
• Week 2: spike integration with real data (even if UI is rough)
• Weeks 3-4: build in parallel
• Week 5: integration, testing with 2-3 community members
• Week 6: launch to full Scenius group

People to involve:

• Jon — already offered the Telethon auth implementation and compute cluster access. Pull him in during week 1 for the Telegram bridge spike. He’s also a good first tester as someone active in the community but not building the tools.
• Kristen was on yesterday’s call — she could be an early tester representing a less technical member’s perspective. If the summaries and rooms make sense to her without explanation, we’re on track.
• Don’t involve more people until we have something working. Feedback on a broken prototype is worse than no feedback.

Resources needed:

• LLM API costs for daily summarization. At 3-5 channels summarized daily, this is maybe $1-2/month with Claude Haiku or GPT-4o-mini. Negligible.
• Hosting: Gabriel’s free server for KG (later), Jon’s cluster as backup. My Community and scenius-digest are already deployed on Vercel. Portico needs hosting — Railway or Jon’s cluster.
• A shared channel (probably the existing Scenius Workshop Telegram group) for coordination during the build.

Risks to watch:

• Telethon auth complexity. Telegram’s API auth is notoriously finicky. Jon’s implementation helps but integrating it into Portico is the unknown. If this blocks for more than a week, fall back to a Telegram bot for read-only room feeds.
• Summary quality. The first LLM summaries will probably be mediocre. Budget time in week 2-3 for prompt iteration based on real channel data, not hypothetical examples.
• Scope creep from the vision. We described emergent rooms, KG-powered topic clustering, cross-community interoperability — all exciting, all out of scope. The MVP is fixed rooms, daily summaries, a dashboard. If either of us starts building KG integration in week 3, that’s a red flag.
• Community expectations. If we announce this too early and it’s half-built, people try it once, have a bad experience, and don’t come back. Soft launch with 3-4 testers first, get it solid, then invite the full group.

On additional development help — realistically, this is a two-person build. The codebase knowledge needed to contribute meaningfully to either Portico or My Community is non-trivial. Onboarding a third developer in week 3 would cost more time than it saves. If the timeline slips, the right response is scope reduction, not adding people. Specifically: drop the LLM summarization pipeline from MVP and ship Portico rooms + My Community dashboard with raw activity feeds. Summaries become a fast follow. That cuts my workload significantly while preserving the core “spatial presence + ambient awareness” experience.

Jon is the exception — he could contribute to the Telethon bridge specifically because he already has a working implementation. But that’s a targeted contribution, not joining the build team.

On community expectations — good catch. The workshop yesterday was essentially a public planning session. People saw the demo, heard the integration ideas, and some will be checking in expecting progress.

The approach: brief async updates in the Workshop Telegram group every 2 weeks. A screenshot, a short message — “here’s where we are, here’s what’s working, here’s what’s next.” Not a launch announcement, just showing work in progress. This keeps the community in the loop without setting a date they’ll hold us to. If someone asks to try it early, that’s how we recruit our week 5 testers organically.

The thing to avoid is going dark for 6 weeks and then doing a big reveal. That creates pressure to ship something polished, and if it’s not ready, the gap between expectations and reality is worse than if people had seen the messy progress along the way.

Participant 2

User shared the following context:

Participant 3

User shared the following context:

Community Pain Points

Information & Communication

• The volume and velocity of information across channels (Telegram, Zoom, Notion, Tldraw) makes it difficult to filter signal from noise, and find relevant things after the fact.
• There is no reliable way to get a high-level view of what has been discussed, decided, or shared over time.
• Telegram’s lack of threading causes important conversations to get buried or lost.
• Members struggle to keep up with group activity.

Coordination & Decision-Making

• The group cannot confidently agree on what to do next, why, or how to act on it.
• Ideas and initiatives are regularly proposed but tend to fizzle out before execution.
• A small number of members carry a disproportionate share of the work.
• The activation energy required to initiate something feels too high, discouraging participation.

Structure & Roles

• Accountability is diffuse and follow-through is inconsistent.
• There is no lightweight streamlined process for moving from ideation to approved action (though we have tried).
• Members have no clear way to know what they are empowered to do independently versus what requires group input.
• Newly on-boarded members feel completely disoriented and lost as to what they can do and where anything is.

Knowledge & Memory

• The group’s collective knowledge and history is not easily navigable or queryable.
• Valuable resources shared across threads are not connected or surfaced relationally.

Information Overload for sure.

One thing I forgot to mention is that there is a WIP proposal for restructuring the Telegram Supergroup. Here’s what it is:

The proposal attempts to address information overload in the Sensemaking Scenius Telegram community by restructuring it into three layers:

1. A simplified main supergroup with just 3–4 core topics (General Chat, Links & Resources, Events, Governance) — reducing noise for everyone.
2. Opt-in interest subgroups (2–5 per member) for deeper focus areas like AI tools, fundraising, or politics, each with a volunteer steward. Members self-select based on their interests.
3. The Sensemaking Drip — a read-only synthesis channel that auto-generates digests of activity across all subgroups and sync calls, so members can stay informed without following everything.

The guiding principle is: simplify what everyone sees, expand what people can opt into, and keep a synthesis layer so nothing important gets lost. It also includes a privacy baseline for how archived and public-facing content is handled.

There’s another issue that I think exists in the community: a lack of shared co-presence and collaboration outside of bi-weekly town halls.

As for tool intersections, I see:

• Portico as the base
• Knowledge Graph Builder as a supporting backend to get all community data from
• Features from My Community integrated such as aggregated links, post feeds, and event feeds.
• Navidrome Jam integrated as an optional jukebox for the space, per-room.
• The Telegram restructuring makes me think “rooms” could correspond with the restructuring such that the “main” room is the main supergroup, and there are other rooms per interest supgroup. The Sensemaking Drip could be not in a room, but in a little community board that gives you a high-level view of the whole community. Entering a room shows you a scoped view of just that room. So rooms are not only aligned with the telegram groups but double as digital spaces to hang out, chat, and jam together.

• If other members are in the space, they’ll see them there
• A recent activity feed
• A curated view of key resources/links for that topic

A shared quiet digital space for the Sensemaking Scenius community where everything is in reach. Build together, explore together, chat together, check out what others are doing, stay up to date, engage as needed, and have fun making sense together.

The very first MVP would probably be Portico + spatial rooms, + my community features (integrating events and the scenius digest drip tg channel artem built) as a community board in the app.

It already has 4 general “rooms” so I think we just keep those for now as we wait for the TG restructuring to happen.

Division of Work:

• Artem could look into adding the scenius digest sensemaking drip to Portico.
• I could get Portico hosted and fix some bugs so we can test it

Key Decisions:

• Identity / Login mechanism
• If we agree on what to build

Dependencies:

• Portico being made open-source / hosted / shared
• Onboarding Artem into Portico
• Artem onboarding me into Sensemaking Drip Digest

People/Resources:

• Maybe loop in Jon Bo since he did some work on this front
• Maybe also Kristen since she’s spearheading the telegram restructuring

Risks:

• I don’t see any risks other than not getting community feedback early enough and not keeping our iterations tight so we don’t get carried away with something the community doesn’t want.

Telegram-based.

Yes some final thoughts:

• I think bumping the knowledge graph builder into this is more important than not.
• The kg builder needs to be hosted, index historical data, index stuff as it comes in, and have a set of general REST API endpoints that wrap SPARQL queries for easy integration as well as the raw SPARQL endpoint. It also needs auth.
• Spoke with Artem and he’s gonna try to add the scenius digest to portico as a first step