Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

Depinkit Messaging App Example

A demonstration of UCAN-protected messaging using the Depinkit stack (Actor + Network + UCAN).

Overview

This example shows how to build a decentralized messaging application with fine-grained, capability-based access control. It demonstrates both hierarchical permissions (admin-controlled channels) and peer-to-peer permissions (direct chat invitations).

Features

  • 🔐 UCAN-Based Authorization: Capability tokens control who can read/write to channels and who can send direct messages
  • 📺 Public Channels: Admin-controlled pub/sub channels with separate read/write permissions
  • 💬 Direct Messaging: Peer-to-peer chat with reciprocal invitations
  • 🎭 Actor Model: Concurrent, message-passing architecture
  • 🌐 P2P Network: Libp2p-based decentralized communication

Architecture

Actors

  1. Admin: Root authority that creates channels and grants permissions
  2. Alice: User with read + write access to #general
  3. Bob: User with read-only access to #general

Capabilities

Channel Permissions (Hierarchical)

  • /channel/{name}/read - Subscribe and receive messages
  • /channel/{name}/write - Publish messages to channel

Direct Chat (Peer-to-Peer)

  • /chat - Send direct messages between invited users

Demo Flow

Phase 1: Setup

  • Create 3 actors (Admin, Alice, Bob)
  • Connect peers via libp2p
  • Subscribe all actors to #general channel

Phase 2: Hierarchical Permissions

  • Admin grants Alice: read + write on #general
  • Admin grants Bob: read only on #general

Phase 3: Channel Communication

  • Admin posts announcement → SUCCESS ✓
  • Alice posts message (has write) → SUCCESS ✓
  • Bob attempts to post (no write) → DENIED ✗
  • All can read messages → SUCCESS ✓

Phase 4: Peer-to-Peer Invitations

  • Alice invites Bob to chat (reciprocal granting)
  • Both can now send direct messages to each other

Phase 5: Direct Messaging

  • Alice sends DM to Bob → SUCCESS ✓
  • Bob replies to Alice → SUCCESS ✓
  • Uninvited users cannot DM → DENIED ✗

UCAN Token Flow

Hierarchical (Admin → User)

Admin creates token: "/channel/general/write" for Alice
   ↓
Token added to Admin's REQUIRE list (Admin accepts Alice's messages)
   ↓
Token added to Alice's PROVIDE list (Alice proves she has permission)
   ↓
Alice publishes to channel with token
   ↓
Validators check token → Accept ✓

Peer-to-Peer (Alice ↔ Bob)

Alice grants Bob: "/chat"
   → Bob can send to Alice
   
Bob grants Alice: "/chat"
   → Alice can send to Bob
   
Both directions enabled = Bidirectional chat ✓

Code Structure

messaging/
├── main.go           # Demo flow and phases
├── actors.go         # Actor creation with network and UCAN setup
├── capabilities.go   # UCAN granting functions
├── handlers.go       # Message handlers and validators
├── types.go          # Message type definitions
├── go.mod            # Dependencies
└── README.md         # This file

Clean Separation

  • main.go: Only interaction logic, no implementation details
  • actors.go: Encapsulates actor/network/UCAN setup
  • capabilities.go: All permission granting logic
  • handlers.go: Message handling and publishing
  • types.go: Data structures only

Running the Example

cd /home/ddz/Lab/depinkit/examples/messaging
go mod tidy
go run .

Expected Output

╔════════════════════════════════════════════════════════╗
║    Depinkit Messaging App - UCAN-Protected Chat       ║
╚════════════════════════════════════════════════════════╝

📡 Phase 1: Creating actors...
[Admin] Creating actor on TCP:8000 QUIC:8001
[Admin] DID: did:key:z6Mk...
[Alice] Creating actor on TCP:8010 QUIC:8011
[Alice] DID: did:key:z6Mk...
[Bob] Creating actor on TCP:8020 QUIC:8021
[Bob] DID: did:key:z6Mk...

🔗 Phase 2: Connecting peers...
✓ Alice connected to Admin
✓ Bob connected to Admin

📺 Phase 3: Setting up #general channel...
[Admin] Subscribed to #general
[Alice] Subscribed to #general
[Bob] Subscribed to #general

🔐 Phase 4: Granting channel permissions...
  • Admin grants Alice: read + write on #general
  • Admin grants Bob: read only on #general

💬 Phase 5: Channel communication...
[Admin] 📢 #general | Admin: Welcome to #general everyone!
[Alice] 📢 #general | Admin: Welcome to #general everyone!
[Bob] 📢 #general | Admin: Welcome to #general everyone!

[Admin] 📢 #general | Alice: Hello everyone! Happy to be here!
[Alice] 📢 #general | Alice: Hello everyone! Happy to be here!
[Bob] 📢 #general | Alice: Hello everyone! Happy to be here!

Bob publish failed (expected): [permission denied]

📱 Phase 6: Setting up direct messaging...
[Admin] Direct message handler ready
[Alice] Direct message handler ready
[Bob] Direct message handler ready

🤝 Phase 7: Peer-to-peer chat invitations...
  • Alice invites Bob to chat
  ✓ Alice and Bob can now chat

✉️  Phase 8: Direct messaging...
[Bob] 💬 DM from Alice: Hey Bob! Want to work on a project together?
[Alice] 💬 DM from Bob: Absolutely! Let's discuss in DM.
[Bob] 💬 DM from Alice: Great! I'll send you the details.

════════════════════════════════════════════════════════════
✅ Demo completed successfully!
════════════════════════════════════════════════════════════

Demonstrated:
  ✓ Hierarchical permissions (Admin → Users)
  ✓ Fine-grained access control (read vs write)
  ✓ UCAN-protected pub/sub channels
  ✓ Peer-to-peer chat invitations
  ✓ Direct actor-to-actor messaging

Key Concepts

1. REQUIRE vs PROVIDE Tokens

  • REQUIRE: "I accept messages from X with capability Y"

    • Added to receiver's context
    • Controls who can talk TO you
  • PROVIDE: "I can prove I have capability Y"

    • Added to sender's context
    • Proves what you can do

2. Bidirectional Communication

For two actors to communicate, both need:

  • Sender: PROVIDE tokens (to prove capability)
  • Receiver: REQUIRE tokens (to accept sender)

3. Validation Layers

  • Network Layer: Pub/sub validators check write permissions before broadcast
  • Actor Layer: Behavior capability checks validate direct messages

Learning Resources

Extending the Example

Ideas for extending this example:

  1. Multiple Channels: Create #dev, #random channels with different permissions
  2. Role Hierarchy: Implement moderators, regular users, guests
  3. Dynamic Permissions: Add/revoke permissions at runtime
  4. Message History: Persist and replay channel history
  5. Presence: Track online/offline status
  6. Typing Indicators: Real-time typing notifications
  7. File Sharing: Share files with UCAN-protected access

License

Part of the Depinkit project.