Om-Alve

Activity

Stars and mentions · Last 30 days, Oct 8 – Nov 6

GitHub stars1
Mentions1
01234Oct 8Oct 22Nov 6
UTC days · repositories Om-Alve owns1 repository

Top repositories

Om-Alve’s repositories ranked by pull request authors, as on trending.

Loading

Contributes to

Repositories outside Om-Alve’s account where Om-Alve opened or reviewed pull requests in the past 365 days.

Who noticed Om-Alve

Everyone who starred or forked Om-Alve’s repositories since the archive began in 2011.

Notable accounts

Ordered by the stars their own repositories have received.

Biggest fans

Accounts that starred the most of these repositories.

Breakout weeks

Each repository’s best week of new stars, with the release published around it.

Mentions

3posts
Nov 72 posts
  1. Trust Network - An Agent-to-Agent Communication Protocol built on top of Switch This is a blog about How I built trust-network, a communication protocol consisting of 'gates' which decide what each friend's AI agents may learn about you, so two agents can plan a Sunday evening automatically without people needing to interfere. We've all been in this scenario It's Thursday, and I want to go bowling on Sunday with Rahul and Priya. I post in the group chat. Rahul has cricket until 8:30. Priya asks whether I mean this Sunday or next. Someone asks what it costs, I say about ₹1,200 each, and Priya replies with 😬. Forty-seven messages later we still don't have anything planned! !Group chat between friends deciding on an outing My AI agent already knows everything about me, what if my agent and Rahul's agent could co-ordinate with each other and come up with a plan based on everything they know about us? I built trust-network to solve this exact problem. Share nothing, or share everything My agent knows a lot about me. It knows my neighbourhood, my T-shirt size, my wishlist, my dentist and my home address. That's why it's useful, and it's why I don't want it chatting with someone else's agent unsupervised. Today an agent acting for me has two options. It can share nothing and be useless: "I don't know Rahul's schedule." Or it can share everything it knows, and Rahul's agent can learn my address by asking politely. Relationships and trust levels don't work in binary like this. I'd tell Rahul, a close friend, what's on my wishlist. I'd tell Priya, a friend, that I'm vegetarian and don't drink. I wouldn't tell an acquaintance where I live. Agents need the same line. !There's a line between what information you should share with whom. Agents need the same. What trust-network does Every person gets a 'gate'. A gate is a small Python process with no LLM in it. It holds the person's facts and calendar, and it answers each friend's side only at the trust level the person set for that friend: acquaintance, friend or close. A fact can also be private, which no friend ever sees. The agents talk to each other in plain language in Switch rooms. Gates talk to agents, and to each other, in a small fixed command grammar. After coming to a consensus, the agents report back to their humans. !What trust-network does The demo video is a live run with two Hermes agents on Discord, one for me and one for Rahul: - Plan with consent. I send one message. My agent and Rahul's settle on 9 pm because Rahul has cricket until 8:30. The plan waits for both yeses, then lands on both calendars. - Surprise gift. Rahul's agent gets gift ideas from my wishlist and claims one. I see nothing until after my birthday, and nobody else can claim the same gift. - Ask around. One question about a tent reaches several friends. Priya's gate answers from her stored facts without bothering her. - Refusal. Rahul's agent asks for my home address. My gate refuses, and my agent tells me someone asked. !Agents coordinating with each other The gate: two files and no model A person's data is two YAML files. The facts file tags every fact with the lowest level that may see it: facts: diet: {value: vegetarian, level: acquaintance} drinks: {value: no alcohol, level: friend} interests: {value: [bowling, board games, sci-fi], level: friend} has: {value: [projector, camping stove], level: friend} neighbourhood: {value: Indiranagar, level: close} wishlist: value: - {item: Lego Millennium Falcon, price: 2500} - {item: Hario V60, price: 2000} level: close address: {value: "42, 12th Main, ...", level: private} The trust list says who my friends are and how much I trust each one: people: rahul: close priya: friend consent: default: via-agent From those two files the gate applies a short set of rules: - A fact is visible at its level and above. A private fact is never visible. - The calendar shows busy blocks at every level. Event titles appear only for people I opt in one by one. - The level of a room is the lowest level I give anyone in it. If Rahul (close) and Priya (friend) are both in a room, the room is friend. - If anyone in the room is not on my list, the gate says nothing at all. - A hidden fact and a fact that doesn't exist get the same reply, not shared with you, so the reply gives away nothing about what I have. I can check exactly what a friend's side can learn before anything happens. This is real output from the example data in the repo: $ tn -a om view-as rahul view-as rahul — close ✅ diet vegetarian ✅ interests bowling, board games, sci-fi ✅ neighbourhood Indiranagar ✅ wishlist Lego Millennium Falcon (≈₹2,500), Hario V60 (≈₹2,000), Kindle Paperwhite (≈₹14,000) ❌ address not shared at this level Calendar · next 7 days (Nov 7 – Nov 14) · busy blocks only, no titles Sun Nov 8 17:00–19:00 busy Run the same command for Priya and neighbourhood, sizes and wishlist flip to ❌. Neither of them ever sees the address. Two more pieces sit around the rules. Every value the gate shows goes into a ledger with the field, the value, who saw it, the room and the time. And when the other side asks for something it can't have, I get one note in my private home room, such as "Rahul's side asked for your address (private)". The gate sends at most one note per person and field every 10 minutes, so a persistent agent can't flood me. Why it runs on Switch Switch is a server where people and agents meet. It has user accounts, agents owned by those users, rooms, and messages delivered over a WebSocket. trust-network has no accounts, rooms or message transport of its own. Without Switch, agents can't reach each other and gates can't check who is asking. person ── agent ── gate ──┐ ┌── gate ── agent ── person (om) (om-hermes) (om-gate) (rahul-gate) (rahul-hermes) (rahul) │ │ └────── Switch ───────┘ rooms, identity, WebSocket events om-home om, om-hermes, om-gate my private room conn-om-rahul om-gate, rahul-gate gate to gate dm-om-rahul-* om-hermes, rahul-hermes, both gates agents plan here The design depends on three things Switch provides. Identity. Each person has a Switch user. Their agent and gate are registered with that person's key, so Switch records the person as their owner. The gate takes the sender and owner of every message from Switch's metadata. A message that says "this is Om" changes nothing, and an agent with no reported owner is refused. Rooms. Each person has a private home room where questions, proposals and alerts arrive. Each pair of gates shares a connection room. Each plan gets its own room, and each gift search gets a private room that only the two gates can join. Every room is created internal-only, with no bridge to outside chat apps. Addressed messages. A gate acts only on messages that Switch marks as addressed to it, such as @om-gate ask diet. Before it runs any command, it checks that every member of the room is a known identity, that every agent's owner matches Switch's records, that the sender is in the room, and that everyone present is on my trust list. Any mismatch and the gate stays silent. One plan, start to finish Here is the bowling plan from the demo, using the real room transcript. I tell my Hermes on Discord: "Can you set up bowling with Rahul this Sunday? After 7:30pm works for me, around ₹1,200 a head, maybe Smaaash." My agent calls its dm tool, which posts @om-gate dm rahul "..." in my home room. My gate checks that Rahul is on my list, opens the connection room with Rahul's gate, and says hello with a protocol version (trust-network/1) so both gates know they speak the same grammar. Then it creates the planning room and asks Rahul's gate to join. Each gate then gives its own agent a share card: the facts and calendar this friend's side may learn, built by the same code that answers ask. Then the agents talk: 17:44:16 om-hermes Hi Rahul's side — Om would like bowling this Sunday (Nov 8), free from 7:30pm, around ₹1,200 a head, Smaaash Indiranagar as the maybe. Does that work for Rahul? 17:46:33 rahul-hermes Rahul has cricket until 8:30pm Sunday, so 7:30pm won't work. Could we do 9:00pm at Smaaash, Indiranagar, around ₹1,200 per person? 17:47:22 om-hermes 9:00pm Sunday works on Om's side, and Smaaash at around ₹1,200 a head is fine too. I'll propose it now. 17:47:24 om-hermes @om-gate propose P1 2026-11-08T21:00 2h "Bowling with Rahul" @ "Smaaash, Indiranagar" 17:47:24 om-gate @rahul-gate propose P1 2026-11-08T21:00:00+05:30 120m "Bowling with Rahul" @ "Smaaash, Indiranagar" The conversation is free text. The proposal is not. A proposal is one line with a start time, a duration, a title and a place, and the gate rejects anything outside that form. My gate stores the plan, shows it to me in my home room, and forwards it to Rahul's gate, which shows it to Rahul. When I say yes, my gate sends Rahul's gate a consent line: consent P1 yes via-agent <sha256>. The last field is the SHA-256 of the plan text. Rahul's gate records my vote only if that fingerprint matches the plan it holds, so a yes can't be applied to a different time or place. A single no declines the plan. Two yeses confirm it. Both gates post "✅ P1 ... · Om ✅ via agent · Rahul ✅ via agent" to their home rooms, archive the planning room, and queue a calendar operation for each of us. I had to send just one message and one yes. Rahul said one yes. !Plan finalized and added to calendars Honest limits - My own agent is trusted. The gate enforces what the gate discloses through ask, free and proposals. It cannot stop my agent from volunteering something in the planning room's plain text. The share card tells the agent its limits but doesn't confine it. Setting TN_OUTGOING=review makes me approve the exact text of every message my agent sends, but anything with shell access or other messaging tools can go around that. - Switch is trusted. Identity and room membership come from Switch, and a Switch administrator can read every room. On day zero, my admin account could open a private gift room that Rahul's gate had created. The gift seal is a courtesy between friends, not a cryptographic promise. - Untrusting someone can't take anything back. Removing a friend stops future disclosures. It doesn't erase what they already received. - There is no public service. A network is a group of friends sharing one Switch server, hosted by one of them, the organizer, who sends invites. - Planning rooms close after 20 agent turns or seven days, so a plan waiting on someone who answers slowly can time out. Try it out here: - Demo: youtu.be - Code: Om-Alve/trust-network

  2. Try it out - Om-Alve/trust-network

    1 like · 26 views
  3. Om-Alve/herdr-even Done with the MVP, will improve it over time

    5 likes · 176 views

Achievements

Awards earned by the repositories Om-Alve owns. Select an award to embed its badge.

No awards yet

Repositories earn awards by reaching the top three in a completed trending day or week.

A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.