top of page

Buzzer brief architecture

Buzzer - is the Decentralized Application (DApp), that runs on Qbit blockchain. Every DApp based on Qbit platform is build on:

  • Specialized or shared shards

  • Specialized transaction types (including validation & processing based on qasm & C++ code)

  • Confirmation scheme (local consensus)

  • Qbit protocol extensions (for nodes, full nodes and light nodes)

Buzzer has several shards (linked to main chain but mostly independent, specialized chain to enable scalability and performance), that contains user data. When @buzzer is created system will assign a shard (most underloaded one) to this buzzer. And all produced user's data from this buzzer will be placed in this shard. Every single transaction (for example "buzz" or TxBuzz), that going to be placed into bound shard should (according to validation scheme) reference special transaction - "fee" or TxFee. TxFee transaction that is fee in QBIT coins, will be consumed by the miner as a reward for the found block. Every shard in Buzzer DApp has it's own consensus based on PoW. Every miner, that found next block will collect all TxFee transactions (of course not linked yet) and make TxBase transaction with collected fees and consequently (just after block was found) crate and broadcast TxBlockBase transaction (on main chain) to claim collected QBIT coins to it's own address.

Buzzer contains following transaction types:

  • TxBuzzer / "buzzer": create unique entity - buzzer with specified entity name (entity name should be unique). Every buzzer transaction has special outs which can be used by buzzer itself to make buzzes (no one else can make original posts from this buzzer except originator - signature check), to make endorsements /mistrusts by other members, to make subscriptions to this buzzer, etc.

  • TxBuzzerInfo / "buzzer_info": create new buzzer info transaction, which contains alias, header and avatar images. Original buzzer name stays intact always.

  • TxBuzzerSubscribe / "buzzer_subscribe": make subscription on given buzzer, this transaction guarantee you, that only active and explicit subscriptions which made by you will be the actual source of personal feed contents. Note: this type of transaction concerning you buzzer can be made only by you with your key.

  • TxBuzzerUnsubscribe / "buzzer_unsubscribe": unsubscribe from buzzer. Make this transaction and you'll never get new data from given buzzer. Note: this type of transaction concerning you buzzer can be made only by you with your key.

  • TxBuzzerEndorse / "buzzer_endorse": this type of transaction add endorsement to the given buzzer. This type of transaction locks 1 QTT token (timelocked transaction) for 30 minutes: TxFee transaction emitted with self-spend out and target height.

  • TxBuzzerMistrust / "buzzer_mistrust": this type of transaction add mistrust value to the given buzzer. This type of transaction also locks 1 QTT token (timelocked transaction) for 30 minutes.

  • TxBuzz / "buzz": make buzz - micro-blog record with attached media. Your buzzer's special out is used to compose this type of transaction. Only you can make buzz from your buzzer, because of key and signature checks, which will be conducted during broadcast transaction (and synchronization of course). 

  • TxBuzzLike / "buzz_like": make like to the corresponding buzz/rebuzz/reply. You can make it only once for the given buzz/rebuzz/reply.

  • TxRebuzz / "rebuzz": repost given buzz to your's buzzer feed with backlink to original buzz.

  • TxRebuzzReply / "rebuzz_reply": make repost of given buzz with comments.

  • TxBuzzReward / "buzz_reward": send to the source buzzer small amount of QBIT coins (1k, 2k or 3k qBIT).

  • TxBuzzerConversation / "buzzer_init_conversation": initialize conversation with selected buzzer. This action can be made only once.

  • TxBuzzerAcceptConversation / "buzzer_accept_conversation": if someone creates conversation with you, you'll get an option to accept this conversation (and vise versa). This transaction type accepts pending conversation.

  • TxBuzzerDeclineConversation / "buzzer_decline_conversation": decline conversation transaction. If you make this action you'll never see any messages and requests from your counterpart.

  • TxBuzzerMessage / "buzzer_message": send encrypted message to the conversation counterpart. Message body and message media will be encrypted using 256 secret key.

  • TxBuzzerMessageReply / "buzzer_message_reply": make reply to the selected message. Reply will be also encrypted as well. Note: this transaction type is not fully supported now.

  • TxBuzzerHide: irreversibly delete your account, without the possibility of further recovery (your QBIT and QTT will remains on your wallet and you can make a new buzzer with the new name).

  • TxBuzzerBlock: blocked user’s content (including posts, replies, messages) will NO longer be visible to you (global, home feeds or in chats), and only to you. This action is local and personal (between you and blocked user), and results of this action are NOT visible to the others (unlike in mistrust). Does not change blocked user’s Trust Score.

  • TxBuzzerUnBlock: unblock the account of another user that you blocked earlier.

As long as Buzzer works in conjunction with Cubix DApp, last have own data store - own shards, own consensus and own miners and validators. Mining rewarding scheme is equals to the scheme implemented in Buzzer DApp.

Cubix allows to store various media types (*.png, *.jpeg, *.mp3, *.mp4, *.m4a, list of supported media will be enlarged), including encryption support of media content data. Media files splitted on linked chunks (similar to file system organization). Each chunk of data represented by special transaction type TxCubixMediaData or "media_data". Every media before broadcasting to the network passes "making preview" procedure and this smaller sample is written to the media header TxCubixMediaHeader / "media_header".

Cubix has transaction types:

  • TxCubixMediaHeader / "media_header": media header transaction. Contains preview data (can be encrypted) of original media file or if media file is small enough - all media file contents. This transaction is the header of media data linked list of TxCubixMediaData.

  • TxCubixMediaData / "media_data": represents media data chunk (can be encrypted). Can be linked to the header, next data chunk or media summary.

  • TxCubixMediaSummary / "media_summary": final transaction of uploaded media. This transaction is the tail of the media data list.

Protocol extensions, which allows to securely select data (indexed) from nodes and full nodes are (this selects operates on transactions and transaction signed details):

  • Select lists of buzzes for personal feed, global feed, buzzer feed

  • Select threaded replies for the given buzz

  • Select lists of followers

  • Select lists of endorsers\mistrusters

  • Select lists of personal events

  • Select lists of conversations and lists of messages

  • Process realtime updates for various feeds

Note: all of the selected feeds pass through "soft commit" technique - lists which come from at least two nodes pass mutual cross-checks. Second level checks - signature verification of selected items. And only those items, which successfully passed all of the mentioned checks will be displayed to the user.

bottom of page