BUDDHA

Buddha Protocol: A three-layered cryptographic communication suite for serverless, brokered, and document-centric messaging.

Abstract

Buddha Protocol (BUDDHA) is a comprehensive communication ASN.1 framework designed for high-security environments. It spans from low-level tactical serverless UDP multicast to high-level document-centric ERP/1 systems, ensuring reliability through formal ASN.1 specifications and modern cryptographic foundations. BUDDHA is built to satisfy both civilian and military communication requirements, incorporating X.509 PKI, XMPP, and X.400 MHS/IPMS patterns under unified BDFL Cathedral. Buddha Protocol is language agnostic and can be used with Erlang, Elixir, C99, Swift, and other languages.

MESSAGE X.894

CMS secured UDP multicast serverless communication for local area networks.

Layer 1: Skynet Serverless Multicast


The first layer MESSAGE-L1.asn1 defines core primitives for peer-to-peer and multi-user communication without a central broker. It uses UDP multicast for discovery and delivery, featuring authority registration and file sharing, including Photo and Audio messages.

0 Basic

0.1 Types
Version ::= INTEGER { v1(1), v2(2), v3(3) }
Flavour ::= ENUMERATED { ericsson(1), nokia(2),
   cisco(3) }
  • Version: Protocol version from v1 to v3.
  • Flavour: Supported operating systems for optimization.

1 Authority

1.1 Server Controlled ABAC Features

ABAC is used as Erlang/OTP application for certificate enrollment.

Feature ::= SEQUENCE {
   id OCTET STRING,
   key OCTET STRING,
   value OCTET STRING,
   group OCTET STRING }
  • id: Unique configuration identifier.
  • key: Semantic name of the feature.
  • value: Current operational parameter.
  • group: Categorical domain isolation.
1.2 Auhthority Method
AuthorityMethod ::= ENUMERATED { announce(0), enroll(1),
   authenticate(2), revoke(3), renew(4), ... }
  • announce: Authority presence discovery.
  • enroll: PKI enrollment entry-point.
  • authenticate: Identity verification via challenges.
  • revoke: Decommissioning of credentials.
  • renew: Extension of validity for certificates.
1.2 Authority

v1: Authority announce is being sent directly from device to device over UDP. Each device has its own CA. v2: Authority is a full mirror of CA CMP protocol.

Authority ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   type AuthorityMethod,
   cert OCTET STRING,
   settings SEQUENCE OF feature Feature, ... }
  • id: Stable administrative authority ID.
  • vsn: Authority protocol version.
  • session: Stateful session token.
  • type: Administrative action type.
  • cert: X.509 certificate encoding.
  • settings: Collection of active features.

2 Message

v1: Message is being sent directly from device to device over UDP. v2: Message is main object in the system and main table in the MNESIA database. Once MessageEventType delivered is sent — it is physically deleted from server.

2.1 Message Type
MessageType ::= ENUMERATED {
   normal(0), sys(1), reply(2),
   forward(3), ... }
  • normal: Standard interpersonal communication.
  • sys: System notification or control message.
  • reply: Message tied to thread context.
  • forward: Relayed content preserving context.
2.2 Message Feed
MessageFeed ::= CHOICE {
   private [1] Privatebox,
   chan [2] Streambox,
   mailbox [3] Mailbox,
   group [4] Groupbox }
  • private: Single-user private delivery.
  • chan: Targeting a broadcast or multicast stream.
  • mailbox: Document-oriented priority delivery system.
  • group: Context for multi-user conference.
2.3 Message

If Message.payload is not present then Message.files should be taken and vice versa.

Message ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   feed MessageFeed,
   payload ContentInfo OPTIONAL,
   type MessageType OPTIONAL,
   linkId OCTET STRING OPTIONAL,
   files SEQUENCE OF file File OPTIONAL,
   mentioned SEQUENCE OF name OCTET STRING OPTIONAL,
   ... }
  • id: Unique identifier for tracking.
  • vsn: Versioning of the message schema.
  • session: Transient session identifier.
  • feed: Dispatch routing information.
  • payload: Secured CMS content.
  • type: Semantic classification of the message.
  • linkId: Reference to parent message ID.
  • files: Identifiers for binary attachments.
  • mentioned: Tagged entities for notification.
2.4 File

v1: File is being sent directly from device to device over UDP. v2: File is a full mirror of N2O FTP protocol.

    File ::= SEQUENCE {
       id OCTET STRING,
       mime OCTET STRING,
       payload ANY,
       parentid OCTET STRING }
  • id: Packet id
  • mime: RFC MIME content tagging.
  • payload: CMS ContentInfo.
  • parentid: Link to parent block.

3 Event

Event is an abstraction for server-directed push messages. v1: Event is being sent directly from device to device over UDP for Message Acknowledgments. v2: Event is controlled by server (mirrors XEP-0022).

3.1 Event

In ASN.1 BUDDHA Core there could be only Message or Presence Events.

Event ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   payload EventPayload, ... }
  • id: Unique event sequence ID.
  • vsn: Protocol version for encoding.
  • session: Network session context.
  • payload: Message or Presence content.
EventPayload ::= CHOICE {
   message   [1] MessageEvent,
   presence  [2] PresenceEvent, ... }
3.2 Message Event Type

Message Event Type covers XEP-0184 (Message Delivery Receipts), XEP-0425 (Message Retraction), XEP-0308 (Last Message Correction).

MessageEventType ::= ENUMERATED { received(1),
   delivered(2), read(3), edited(4), deleted(5),
   updated(6), ... }
  • received: Transport accepted the message.
  • delivered: Message reached target device.
  • read: Recipient viewed the content.
  • edited: Original content was modified.
  • deleted: Remove message from storage.
3.3 Message Event
MessageEvent ::= SEQUENCE {
   type MessageEventType,
   messageId OCTET STRING OPTIONAL,
   feed MessageFeed OPTIONAL,
   actor OCTET STRING OPTIONAL,
   timestamp INTEGER OPTIONAL, ... }
  • type: Specific lifecycle event.
  • messageId: Identifier of affected message.
  • feed: Communication channel context.
  • actor: Entity that triggered the event.
  • timestamp: Precise UTC time of event.
3.4 Presence Event Type

Presence Event Type covers RFC 3921 (Presence), XEP-0085 (Chat State Notifications).

PresenceEventType ::= ENUMERATED { online(1),
   offline(2), typing(3), ... }
  • online: Available for interaction.
  • offline: No longer reachable.
  • typing: Content composition indicator.
3.5 Presence Event
PresenceEvent ::= SEQUENCE {
   type PresenceEventType,
   feed MessageFeed OPTIONAL,
   actor OCTET STRING OPTIONAL,
   timestamp INTEGER OPTIONAL, ... }
  • type: Specific presence transition.
  • feed: Optional channel context.
  • actor: Entity with state change.
  • timestamp: Time of presence update.

CHAT X.509

TLS unicast broker and PKI X.509 infrastructure (ПК КЗІ X.509).

Layer 2: Brokered TLS & PKI


The second layer CHAT-L2.asn1 introduces a central broker architecture with TLS encryption. It implements full X.509 PKI support, LDAP-based search, and complex subscription/presence mechanisms for global messaging systems.

4 Query

Query Layer provides RPC-like request/response mechanism for CHAT infrastructure. Query Layer is mirroring XEP-0148 (IM IQ).

4.1 Query Type
QueryType ::= ENUMERATED { get(1), set(2),
   result(3), error(4), ... }
  • get: Data retrieval request.
  • set: Mutation or state change request.
  • result: Successful operation response.
  • error: Operation failure report.
4.2 Query

Query stanzas covers XEP-0004 (Data Forms), XEP-0030 (Service Discovery) as Store and Process Extenstions from N2O Pro Protocol.

Query ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   queryType QueryType,
   ref [0] OCTET STRING OPTIONAL,
   feed [1] MessageFeed OPTIONAL,
   target [2] OCTET STRING OPTIONAL,
   payload [3] QueryPayload OPTIONAL,
   code [4] INTEGER OPTIONAL, ... }
  • ref: Request correlation ID.
  • feed: Routing context/channel.
  • target: Hints for specific controllers.
  • payload: Extension envelope for data.
  • code: Completion status code.
4.3 Query Cores & Extensions
QueryPayload ::= CHOICE {
   subscription [1] SubscriptionCore,
   presence     [2] PresenceCore,
   person       [3] PersonCore,
   roster       [4] RosterCore,
   member       [5] MemberExtension,
   conference   [6] ConferenceExtension,
   moderation   [7] ModerationExtension,
   inbox        [8] InboxExtension,
   search       [9] SearchExtension,
   bpe          [10] ProcessExtension,
   kvs          [11] StorageExtension,
   mail         [12] MailExtension, ... }

5 Subscription Query Core

Fact of connection between actors and targets.

Subscription ::= SEQUENCE {
   actor Binary,
   target Binary, ... }

SubscriptionQuery ::= SEQUENCE {
   op SubscriptionOp, actor [0] Binary OPTIONAL,
   target [1] Binary OPTIONAL, ... }

SubscriptionAnswer ::= SEQUENCE {
   item [0] Subscription OPTIONAL,
   items [1] SEQUENCE OF subscription
      Subscription OPTIONAL, ... }

SubscriptionCore ::= CHOICE {
   request [1] SubscriptionQuery,
   result  [2] SubscriptionAnswer } 

6 Roster, Presence & Person Cores

Synchronized contact lists and detailed profile information.

PresenceQuery ::= SEQUENCE {
   op PresenceOp,
   actor [0] OCTET STRING OPTIONAL,
   feed [1] MessageFeed OPTIONAL, ... }

PresenceAnswer ::= SEQUENCE {
   item [0] PresenceItem OPTIONAL,
   items [1] SEQUENCE OF item
      PresenceItem OPTIONAL, ... }

PresenceCore ::= CHOICE {
   request [1] PresenceQuery,
   result  [2] PresenceAnswer }
Person ::= SEQUENCE {
   id OCTET STRING,
   nickname OCTET STRING,
   avatar OCTET STRING,
   phone OCTET STRING,
   presence Presence,
   status PersonStatus,
   settings [0] SEQUENCE OF
     feature Feature OPTIONAL, ... }

PersonQuery ::= SEQUENCE {
   op PersonOp,
   id [0] OCTET STRING OPTIONAL,
   name [1] OCTET STRING OPTIONAL, ... }

PersonAnswer ::= SEQUENCE {
   item [0] PersonItem OPTIONAL,
   items [1] SEQUENCE OF
     item PersonItem OPTIONAL, ... }

PersonCore ::= CHOICE {
   request [1] PersonQuery,
   result  [2] PersonAnswer }
Roster ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   nickname OCTET STRING,
   people SEQUENCE OF contact Person,
   topics SEQUENCE OF room Conference,
   channels SEQUENCE OF room Conference,
   status RosterStatus, ... }

RosterQuery ::= SEQUENCE {
   op RosterOp,
   id [0] OCTET STRING OPTIONAL,
   name [1] OCTET STRING OPTIONAL, ... }

RosterAnswer ::= SEQUENCE {
   item [0] RosterItem OPTIONAL,
   items [1] SEQUENCE OF
     item RosterItem OPTIONAL, ... }

RosterCore ::= CHOICE {
   request [1] RosterQuery,
   result  [2] RosterAnswer } 

7 Member & Conference Extensions

Multi-user chat rooms, channels, and group calls. This mirrors XEP-0045 (MUC).

MemberQuery ::= SEQUENCE {
   op MemberOp, actor [0] OCTET STRING OPTIONAL,
   feed [1] MessageFeed OPTIONAL }

MemberAnswer ::= SEQUENCE {
   item [0] MemberItem OPTIONAL,
   items [1] SEQUENCE OF item MemberItem OPTIONAL }

MemberExtension ::= CHOICE {
   request [1] MemberQuery,
   result  [2] MemberAnswer }
Conference ::= SEQUENCE {
   id OCTET STRING,
   vsn Version,
   session OCTET STRING,
   name OCTET STRING,
   members SEQUENCE OF member Member,
   type ConferenceType,
   status ConferenceStatus, ... }

ConferenceQuery ::= SEQUENCE {
   op ConferenceOp, id [0] OCTET STRING OPTIONAL,
   name [1] OCTET STRING OPTIONAL,
   type [2] ConferenceType OPTIONAL, ... }

ConferenceAnswer ::= SEQUENCE {
   item [0] ConferenceItem OPTIONAL,
   items [1] SEQUENCE OF item
      ConferenceItem OPTIONAL, ... }

ConferenceExtension ::= CHOICE {
   request [1] ConferenceQuery,
   result  [2] ConferenceAnswer }

8 Moderation Extension

Server-side access control and restriction policies.

ModerationQuery ::= SEQUENCE {
   op ModerationOp, actor [0] OCTET STRING OPTIONAL,
   target [1] OCTET STRING OPTIONAL, ... }

ModerationAnswer ::= SEQUENCE {
   item [0] ModerationItem OPTIONAL,
   items [1] SEQUENCE OF item
      ModerationItem OPTIONAL, ... }

ModerationExtension ::= CHOICE {
   request [1] ModerationQuery,
   result [2] ModerationAnswer }

9 Inbox Entension

Folder queues management for historical message retrieval. Inbox Extension covers XEP-0313.

InboxMethod ::= ENUMERATED { get(1), erase(2), ...}

Inbox ::= SEQUENCE {
   id OCTET STRING, vsn Version,
   session OCTET STRING, type InboxMethod,
   feed MessageFeed,
   messages [0] SEQUENCE OF
      message Message OPTIONAL, ... }

InboxOp ::= ENUMERATED { get(1), erase(2), ... }

InboxQuery ::= SEQUENCE {
   op InboxOp,
   feed [0] MessageFeed OPTIONAL, ... }

InboxItem ::= SEQUENCE { message Message }

InboxAnswer ::= SEQUENCE {
   items [0] SEQUENCE OF
     item InboxItem OPTIONAL, ... }

InboxExtension ::= CHOICE {
   request [1] InboxQuery,
   result [2] InboxAnswer }

10 Search Extension

Directory lookup and search functions for users and rooms.

SearchQuery ::= SEQUENCE {
   op SearchOp, dn [0] OCTET STRING OPTIONAL,
   field [1] OCTET STRING OPTIONAL,
   value [2] OCTET STRING OPTIONAL,
   criteria [3] Criteria OPTIONAL,
   type [4] Scope OPTIONAL, ... }

SearchItem ::= SEQUENCE {
   dn [0] OCTET STRING OPTIONAL,
   field [1] OCTET STRING OPTIONAL,
   value [2] OCTET STRING OPTIONAL,
   criteria [3] Criteria OPTIONAL,
   type [4] Scope OPTIONAL }

SearchAnswer ::= SEQUENCE {
   items [0] SEQUENCE OF item
      SearchItem OPTIONAL, ... }

SearchExtension ::= CHOICE {
   request [1] SearchQuery,
   result [2] SearchAnswer }

11 Protocol Envelope

Top-level transport envelope for multiplexing protocol units.

CHATProtocol ::= CHOICE {
   authority [1] Authority,
   message   [2] Message,
   event     [4] Event,
   query     [5] Query }

CHATMessage ::= SEQUENCE {
   no INTEGER,
   headers SEQUENCE OF header OCTET STRING,
   body CHATProtocol }

MAIL X.420

ERP/1: Documents protocol regulated by Order #55 of Cabinet of Ministers of Ukraine, implemented as MHS IPMS Priority Mail to be compatible with Order #40 of Ministry of Defense of Ukraine.

Layer 3: Document-Centric MHS / IPMS


The MAIL-L3.asn1 is an extension of layer 2, incorporating InterPersonal Messaging Service (IPMS) and Message Handling System (MHS) patterns from X.400. It is tailored for official document flow, implementing strict ERP/1 requirements of orders #40 and #55.

MAIL-v3 DEFINITIONS IMPLICIT TAGS ::= BEGIN

    IMPORTS CHATProtocol, Message, File
       FROM CHAT-L2 ;

    --- IPMS/MHS Extension for ERP/1

    IPMSHeading ::= SEQUENCE {
        originator      OCTET STRING,
        authorizing     SEQUENCE OF OCTET STRING OPTIONAL,
        primaryRecipients SEQUENCE OF OCTET STRING,
        copyRecipients    SEQUENCE OF
           OCTET STRING OPTIONAL,
        blindCopyRecipients SEQUENCE OF
           OCTET STRING OPTIONAL,
        subject         OCTET STRING,
        priority        INTEGER,
        expiryTime      GeneralizedTime OPTIONAL,
        replyTime       GeneralizedTime OPTIONAL,
        importance      ENUMERATED {
           low(0), normal(1), high(2) },
        sensitivity     ENUMERATED {
           personal(1), private(2),
           companyConfidential(3) }
    }

    DocumentType ::= ENUMERATED {
       draft(0), official(1), signed(2), archived(3) }

    Order40Metadata ::= SEQUENCE {
        documentId      OCTET STRING,
        controlDate     GeneralizedTime,
        executor        OCTET STRING,
        signature       OCTET STRING,
        regulatoryAct   OCTET STRING -- Order №40 MO
    }

    MailMessage ::= SEQUENCE {
        heading IPMSHeading,
        body    SEQUENCE OF CHOICE {
            text [0] OCTET STRING,
            doc  [1] DocumentContent
        },
        meta    Order40Metadata
    }

    DocumentContent ::= SEQUENCE {
        vsn     INTEGER,
        type    DocumentType,
        content ANY,
        files   SEQUENCE OF File
    }

END

BUDDHA Testing DSL

Domain Specific Language for testing and scripting BUDDHA interactions.

DSL Session


The console testing DSL allows for rapid prototyping and validation of protocol flows, from simple P2P messages to complex document submissions.

# BUDDHA Testing Session
connect [email protected]
auth password "secret"
login cert "path/to/cert.der"

# Presence
set presence online "Available"
send presence to alice subscribed

# Messages
send message to alice "Hello there!"
send message to room:general "Hi everyone" reply-to "msg-id-123"

# Rich message
send message {
  to: alice
  subject: "ERP/1 Document Draft"
  body: "Please review the attached Order 40 document."
  priority: high
}

# Acknowledgements
send ack for "msg-id-123"
send read for "msg-id-xyz"

# Group Chat
join room general
invite user bob to room general

# File Transfers
send file "order_40.pdf" to alice
request file "document-id" from bob

# Low level/Raw
send raw hex "3082..."
expect message from alice matching ".*received.*"

Open Source

GitHub Logo