├── CNAME
├── .gitignore
├── favicon.ico
├── assets
    ├── aip-15
    │   └── qr-code.png
    ├── aip-1
    │   └── aip_process.png
    └── main.scss
├── _data
    └── statuses.yaml
├── all.html
├── meta.html
├── api.html
├── arc.html
├── core.html
├── informational.html
├── interface.html
├── networking.html
├── _includes
    ├── aipnums.html
    ├── authorlist.html
    ├── aiptable.html
    ├── header.html
    ├── social.html
    └── footer.html
├── _layouts
    ├── page.html
    └── aip.html
├── 404.html
├── README.md
├── _config.yml
├── AIPS
    ├── aip-15.md
    ├── aip-13.md
    ├── aip-7.md
    ├── aip-6.md
    ├── aip-5.md
    ├── aip-9.md
    ├── aip-2.md
    ├── aip-11.md
    ├── aip-4.md
    ├── aip-17.md
    ├── aip-8.md
    ├── aip-16.md
    ├── aip-12.md
    ├── aip-3.md
    ├── aip-10.md
    ├── aip-14.md
    ├── aip-18.md
    └── aip-1.md
├── index.html
├── aip-X.md
└── LICENSE


/CNAME:
--------------------------------------------------------------------------------
1 | aips.adamant.im


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | _site/
2 | .sass-cache/
3 | .jekyll-metadata
4 | .vscode/


--------------------------------------------------------------------------------
/favicon.ico:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Adamant-im/AIPs/HEAD/favicon.ico


--------------------------------------------------------------------------------
/assets/aip-15/qr-code.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Adamant-im/AIPs/HEAD/assets/aip-15/qr-code.png


--------------------------------------------------------------------------------
/assets/aip-1/aip_process.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Adamant-im/AIPs/HEAD/assets/aip-1/aip_process.png


--------------------------------------------------------------------------------
/_data/statuses.yaml:
--------------------------------------------------------------------------------
1 | - Draft
2 | - Accepted
3 | - Final
4 | - Active
5 | - Deferred
6 | - Replaced
7 | - Rejected
8 | 


--------------------------------------------------------------------------------
/all.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: All AIPs
4 | ---
5 | 
6 | {% include aiptable.html aips=site.pages %}
7 | 


--------------------------------------------------------------------------------
/meta.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: Meta
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Meta" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/api.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: API
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Standards"|where:"category","API" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/arc.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: ARC
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Standards"|where:"category","ARC" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/core.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: Core
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Standard"|where:"category","Core" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/informational.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: Informational
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Informational" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/interface.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: Interface
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Standards"|where:"category","Interface" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/networking.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: Networking
4 | ---
5 | 
6 | {% assign aips=site.pages|where:"type","Standard"|where:"category","Networking" %}
7 | {% include aiptable.html aips=aips %}
8 | 


--------------------------------------------------------------------------------
/_includes/aipnums.html:
--------------------------------------------------------------------------------
1 | {% assign aips=include.aips|split:"," %}
2 | {% for aipnum in aips %}
3 |   <a href="{{aipnum|strip|prepend:"aip-" }}">{{aipnum|strip}}</a>{% if forloop.last == false %}, {% endif %}
4 | {% endfor %}
5 | 


--------------------------------------------------------------------------------
/_layouts/page.html:
--------------------------------------------------------------------------------
 1 | ---
 2 | layout: default
 3 | ---
 4 | <article class="post">
 5 | 
 6 |   <header class="post-header">
 7 |     <h1 class="post-title">{{ page.title | escape }}</h1>
 8 |   </header>
 9 | 
10 |   <div class="post-content">
11 |     {{ content }}
12 |   </div>
13 | 
14 | </article>
15 | 


--------------------------------------------------------------------------------
/404.html:
--------------------------------------------------------------------------------
 1 | ---
 2 | layout: default
 3 | ---
 4 | 
 5 | <style type="text/css" media="screen">
 6 |   .container {
 7 |     margin: 10px auto;
 8 |     max-width: 600px;
 9 |     text-align: center;
10 |   }
11 |   h1 {
12 |     margin: 30px 0;
13 |     font-size: 4em;
14 |     line-height: 1;
15 |     letter-spacing: -1px;
16 |   }
17 | </style>
18 | 
19 | <div class="container">
20 |   <h1>404</h1>
21 | 
22 |   <p><strong>Page not found :(</strong></p>
23 |   <p>The requested page could not be found.</p>
24 | </div>
25 | 


--------------------------------------------------------------------------------
/_includes/authorlist.html:
--------------------------------------------------------------------------------
 1 | {%- assign authors=include.authors|split:"," -%}
 2 | {%- for author in authors -%}
 3 |   {%- if author contains "<" -%}
 4 |     {%- assign authorparts=author|split:"<" -%}
 5 |     <a href="mailto:{{authorparts[1]|remove:">"}}">{{authorparts[0]|strip}}</a>
 6 |   {%- elsif author contains "(@" -%}
 7 |     {%- assign authorparts=author|split:"(@" -%}
 8 |     <a href="https://github.com/{{authorparts[1]|remove:")"}}">{{authorparts[0]|strip}}</a>
 9 |   {%- else -%}
10 |     {{author}}
11 |   {%- endif -%}
12 |   {% if forloop.last == false %}, {% endif %}
13 | {%- endfor -%}
14 | 


--------------------------------------------------------------------------------
/_includes/aiptable.html:
--------------------------------------------------------------------------------
 1 | <style type="text/css">
 2 |   .aiptable .title {
 3 |     width: 67%;
 4 |   }
 5 | 
 6 |   .aiptable .author {
 7 |     width: 33%;
 8 |   }
 9 | </style>
10 | {% for status in site.data.statuses %}
11 |   {% assign aips = include.aips|where:"status",status|sort:"aip" %}
12 |   {% assign count = aips|size %}
13 |   {% if count > 0 %}
14 |     <h2>{{status}}</h2>
15 |     <table class="aiptable">
16 |       <thead>
17 |         <tr><th class="aipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr>
18 |       </thead>
19 |       {% for page in aips %}
20 |         <tr>
21 |           <td class="aipnum"><a href="{{page.url|relative_url}}">{{page.aip|xml_escape}}</a></td>
22 |           <td class="title">{{page.title|xml_escape}}</td>
23 |           <td class="author">{% include authorlist.html authors=page.author %}</td>
24 |         </tr>
25 |       {% endfor %}
26 |     </table>
27 |   {% endif %}
28 | {% endfor %}
29 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # AIPs
 2 | 
 3 | ADAMANT Improvement Proposal (AIPs) repository describe standards for the ADAMANT Messenger platform, including core protocol specifications and client APIs.
 4 | 
 5 | ## Contributing
 6 | 
 7 |  1. Review [AIP-1](AIPS/aip-1.md).
 8 |  2. Fork the repository by clicking "Fork" in the top right.
 9 |  3. Add your AIP to your fork of the repository. There is a [template AIP here](aip-X.md).
10 |  4. Submit a Pull Request to ADAMANT's [AIPs repository](https://github.com/Adamant-im/AIPs).
11 | 
12 | Your first PR should be a first draft of the final AIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new AIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the AIP as a whole.
13 | 
14 | If your AIP requires images, the image files should be included in a subdirectory of the `assets` folder for that AIP as follow: `assets/aip-X` (for aip **X**). When linking to an image in the AIP, use relative links such as `../assets/aip-X/image.png`.
15 | 
16 | When you believe your AIP is mature and ready to progress past the draft phase, you should open a PR changing the state of your AIP to 'Accepted'. An editor will review your draft and ask if anyone objects to its being accepted. After that implementation will start. And state will be change to 'Final' as soon as implementation will be done and pushed live
17 | 


--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
 1 | # Welcome to Jekyll!
 2 | #
 3 | # This config file is meant for settings that affect your whole blog, values
 4 | # which you are expected to set up once and rarely edit after that. If you find
 5 | # yourself editing this file very often, consider using Jekyll's data files
 6 | # feature for the data you need to update frequently.
 7 | #
 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use
 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process.
10 | 
11 | # Site settings
12 | # These are used to personalize your new site. If you look in the HTML files,
13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
14 | # You can create any custom variable you would like, and they will be accessible
15 | # in the templates via {{ site.myvariable }}.
16 | title: ADAMANT Improvement Proposals
17 | description: >-
18 |   ADAMANT Improvement Proposals (AIPs) describe standards for the ADAMANT Messenger
19 |   platform, including core protocol specifications and client APIs.
20 | url: "http://aips.adamant.im"
21 | twitter_username: adamant_im
22 | github_username:  Adamant-im
23 | header_pages:
24 |  - all.html
25 |  - core.html
26 |  - networking.html
27 |  - interface.html
28 |  - arc.html  
29 |  - api.html
30 |  - informational.html
31 |  - meta.html
32 | 
33 | # Build settings
34 | markdown: kramdown
35 | 
36 | kramdown: 
37 |   input: GFM
38 | theme: minima
39 | plugins:
40 |   - jekyll-feed
41 | 
42 | permalink: /:slug
43 | 
44 | defaults:
45 |   -
46 |     scope:
47 |       path: "AIPS"
48 |     values:
49 |       layout: "aip"
50 | 
51 | exclude:
52 |   - Gemfile
53 |   - Gemfile.lock
54 |   - node_modules
55 |   - vendor/bundle/
56 |   - vendor/cache/
57 |   - vendor/gems/
58 |   - vendor/ruby/
59 |   - aip-X.md
60 | 


--------------------------------------------------------------------------------
/_includes/header.html:
--------------------------------------------------------------------------------
 1 | <header class="site-header" role="banner">
 2 |   <div class="wrapper">
 3 |     <div class="uk-position-top-left">
 4 |       <a href="https://adamant.im" class="uk-navbar-item uk-adm-logo" target="_blank">
 5 |       <img src="https://adamant.im/media/admlogo.svg" class="uk-responsive-height" alt=""></a>
 6 |     </div>
 7 |     {%- assign default_paths = site.pages | map: "path" -%}
 8 |     {%- assign page_paths = site.header_pages | default: default_paths -%}
 9 |     <a class="site-title" rel="author" href="{{ "/" | relative_url }}">{{ site.title | escape }}</a>
10 | 
11 |     {%- if page_paths -%}
12 |       <nav class="site-nav">
13 |         <input type="checkbox" id="nav-trigger" class="nav-trigger" />
14 |         <label for="nav-trigger">
15 |           <span class="menu-icon">
16 |             <svg viewBox="0 0 18 15" width="18px" height="15px">
17 |               <path d="M18,1.484c0,0.82-0.665,1.484-1.484,1.484H1.484C0.665,2.969,0,2.304,0,1.484l0,0C0,0.665,0.665,0,1.484,0 h15.032C17.335,0,18,0.665,18,1.484L18,1.484z M18,7.516C18,8.335,17.335,9,16.516,9H1.484C0.665,9,0,8.335,0,7.516l0,0 c0-0.82,0.665-1.484,1.484-1.484h15.032C17.335,6.031,18,6.696,18,7.516L18,7.516z M18,13.516C18,14.335,17.335,15,16.516,15H1.484 C0.665,15,0,14.335,0,13.516l0,0c0-0.82,0.665-1.483,1.484-1.483h15.032C17.335,12.031,18,12.695,18,13.516L18,13.516z"/>
18 |             </svg>
19 |           </span>
20 |         </label>
21 | 
22 |         <div class="trigger">
23 |           {%- for path in page_paths -%}
24 |             {%- assign my_page = site.pages | where: "path", path | first -%}
25 |             {%- if my_page.title -%}
26 |             <a class="page-link" href="{{ my_page.url | relative_url }}">{{ my_page.title | escape }}</a>
27 |             {%- endif -%}
28 |           {%- endfor -%}
29 |         </div>
30 |       </nav>
31 |     {%- endif -%}
32 |   </div>
33 | </header>
34 | 


--------------------------------------------------------------------------------
/AIPS/aip-15.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 15
 3 | title: QR codes for ADAMANT addresses
 4 | author: Aleksei Lebedev (@adamant-al)
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/33
 6 | status: Accepted
 7 | requires: 8, 9
 8 | type: Standards
 9 | category: ARC
10 | created: 2019-02-20
11 | ---
12 | 
13 | <!--You can leave these HTML comments in your merged AIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
14 | 
15 | ## Simple Summary
16 | 
17 | A standard way of generating ADAMANT QR codes with addresses.
18 | 
19 | ## Abstract
20 | <!--A short (~200 word) description of the technical issue being addressed.-->
21 | 
22 | QR code is a convenient way for sharing ADAMANT address. General URI for addresses described in [AIP-8](https://aips.adamant.im/AIPS/aip-8) and [AIP-9](https://aips.adamant.im/AIPS/aip-9).
23 | 
24 | ## Motivation
25 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
26 | Well known view of ADAMANT QR codes with addresses helps users to understand if QR code includes ADAMANT address or not.
27 | 
28 | ## Specification
29 | 
30 | QR code design must include informational part (URI) and ADAMANT logo in the center of QR.
31 | 
32 | ### Examples
33 | 
34 | ![QR code sample](../assets/aip-15/qr-code.png)
35 | 
36 | QR data contents: https://msg.adamant.im?address=U9821606738809290000&label=John+Doe&action=send_message&message=Just+say+hello
37 | 
38 | ## Copyright
39 | 
40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
41 | 


--------------------------------------------------------------------------------
/AIPS/aip-13.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 13
 3 | title: Public non-ADM wallet addresses
 4 | author: Aleksei Lebedev
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/31
 6 | status: Accepted
 7 | type: Standards
 8 | category: ARC
 9 | created: 2019-02-20
10 | requires: 3
11 | ---
12 | 
13 | Storing public non-ADM wallet addresses in the ADAMANT blockchain.
14 | 
15 | ## Simple Summary
16 | 
17 | Define a way to store non-ADM wallet addresses (i.e. Ether, DOGE) in the blockchain.
18 | 
19 | ## Abstract
20 | 
21 | Transferring tokens in chats is one of essential ADAMANT features. It allows to send different external (non-ADM) tokens to interlocutors without specifying any token addresses. To make storing and sending tokens secure, only user has control over private keys for these tokens. See [ADAMANT Messenger: Secure ETH Transfers](https://medium.com/adamant-im/adamant-messenger-secure-eth-transfers-b27984a3ce05) for details.
22 | 
23 | In-chat payments are possible due to public wallet addresses stored in blockchain. Any client app can fetch user's wallet address and use it to send tokens in its own blockchain. E.g., to send Ethers to ADAMANT user U11977883563659338220 in chat, client app can fetch public record with ETH address of U11977883563659338220, and send correspondent transaction to Ethereum network.
24 | 
25 | ## Specification
26 | 
27 | Public wallet addresses are stored as JSON objects in the ADAMANT KVS as described in the [AIP-3](https://aips.adamant.im/AIPS/aip-3). This objects *must be public* and passed as `value` with `key` like `ticker:address`.
28 | 
29 | ### Examples
30 | 
31 | ``` json
32 | {
33 |   "transaction": {
34 |     "type": 9,
35 |     "amount": 0,
36 |     "senderId": "U11977883563659338220",
37 |     "senderPublicKey": "d2cbc26c2ef6...",
38 |     "asset": {
39 |       "state": {
40 |         "key": "eth:address",
41 |         "value": "0xf4a2d5997eb0575b7ad7c10b0b178524c336f9e9",
42 |         "type": 0
43 |       }
44 |     },
45 |     "timestamp": 45603372,
46 |     "signature": "86cbe525042bf83802..."
47 |   }
48 | }
49 | 
50 | ```
51 | 
52 | This transaction write public Ether address for U11977883563659338220.
53 | 
54 | ## Copyright
55 | 
56 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
57 | 


--------------------------------------------------------------------------------
/AIPS/aip-7.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 7
 3 | title: Contacts List
 4 | author: Alexander Kiselev (@MaaKut)
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/11
 6 | status: Accepted
 7 | type: Standards
 8 | category: ARC
 9 | created: 2018-07-30
10 | requires: 3
11 | ---
12 | 
13 | Storing Contacts list in the ADAMANT blockchain.
14 | 
15 | ## Simple Summary
16 | 
17 | Define a way to store Contacts (i.e. user-defined aliases for the ADAMANT addresses) in the blockchain.
18 | 
19 | ## Abstract
20 | 
21 | In order to improve user experience, ADAMANT clients should provide a way to assign aliases to the addresses user interacts with. These aliases needed to be stored in the ADAMANT blockchain in order to be accessible from any ADAMANT client.
22 | 
23 | ## Specification
24 | 
25 | Contacts list is stored as a JSON object in the ADAMANT KVS as described in the [AIP-3](https://aips.adamant.im/AIPS/aip-3). This object *must be encrypted* and passed as `value` with `key` = `contact_list`.
26 | 
27 | The keys of the above JSON are ADAMANT UIDs, values are objects, where aliases are stored in the `displayName` property.
28 | 
29 | Example of `value` object for storing Contact list:
30 | 
31 | ``` json
32 | {
33 |   "U9821606738809290000": {
34 |     "displayName": "John Doe"
35 |   },
36 |   "U9821606738809290001": {
37 |     "displayName": "Jane Doe"
38 |   }
39 | }
40 | ```
41 | 
42 | Other properties besides `displayName` may be added to values to store various contact details.
43 | 
44 | Note, that contacts lists may contain sensitive info and, therefore, must be encrypted (see [AIP-3](https://aips.adamant.im/AIPS/aip-3)).
45 | 
46 | ### Examples
47 | 
48 | ``` json
49 | {
50 |   "transaction": {
51 |     "type": 9,
52 |     "amount": 0,
53 |     "senderId": "U15677078342684640219",
54 |     "senderPublicKey": "e16e624fd0...",
55 |     "asset": {
56 |       "state": {
57 |         "key": "contact_list",
58 |         "value":"{
59 |           \"message\": \"6df8c172feef228d930130...\",
60 |           \"nonce\": \"f6c7b76d55db945bb026cd221d5...\"}",
61 |         "type": 0
62 |       }
63 |     },
64 |     "timestamp": 45603645,
65 |     "signature": "dbafce549f1..."
66 |   }
67 | }
68 | ```
69 | 
70 | Sends private (encrypted) contact_list records for U15677078342684640219.
71 | 
72 | ## Copyright
73 | 
74 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
75 | 


--------------------------------------------------------------------------------
/_layouts/aip.html:
--------------------------------------------------------------------------------
 1 | ---
 2 | layout: default
 3 | ---
 4 | 
 5 | <div class="home">
 6 |   <h1 class="page-heading">
 7 |     AIP {{ page.aip | xml_escape }}: {{ page.title | xml_escape }}
 8 |     <a href="{{site.github.repository_url}}/blob/master/{{page.path}}"><svg role="img" aria-label="Source"
 9 |         xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16">
10 |         <title>Source</title>
11 |         <path fill-rule="evenodd"
12 |           d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z" />
13 |       </svg></a>
14 |   </h1>
15 |   <table>
16 |     <tr>
17 |       <th>Author</th>
18 |       <td>{% include authorlist.html authors=page.author %}</td>
19 |     </tr>
20 |     {% if page["discussions-to"] != undefined %}
21 |     <tr>
22 |       <th>Discussions-To</th>
23 |       <td><a href="{{ page[" discussions-to"] | uri_escape }}">{{ page["discussions-to"] | xml_escape }}</a></td>
24 |     </tr>
25 |     {% endif %}
26 |     <tr>
27 |       <th>Status</th>
28 |       <td>{{ page.status | xml_escape }}</td>
29 |     </tr>
30 |     <tr>
31 |       <th>Type</th>
32 |       <td>{{ page.type | xml_escape }}</td>
33 |     </tr>
34 |     {% if page.category != undefined %}
35 |     <tr>
36 |       <th>Category</th>
37 |       <td>{{ page.category | xml_escape }}</td>
38 |     </tr>
39 |     {% endif %}
40 |     <tr>
41 |       <th>Created</th>
42 |       <td>{{ page.created | xml_escape }}</td>
43 |     </tr>
44 |     {% if page.updated != undefined %}
45 |     <tr>
46 |       <th>Updated</th>
47 |       <td>{{ page.updated | xml_escape }}</td>
48 |     </tr>
49 |     {% endif %}
50 |     {% if page.requires != undefined %}
51 |     <tr>
52 |       <th>Requires</th>
53 |       <td>{% include aipnums.html aips=page.requires %}</td>
54 |     </tr>
55 |     {% endif %}
56 |     {% if page.replaces != undefined %}
57 |     <tr>
58 |       <th>Replaces</th>
59 |       <td>{% include aipnums.html aips=page.replaces %}</td>
60 |     </tr>
61 |     {% endif %}
62 |     {% if page["replaced-by"] != undefined %}
63 |     <tr>
64 |       <th>Replaced by</th>
65 |       <td>{% include aipnums.html aips=page.replaced-by %}</td>
66 |     </tr>
67 |     {% endif %}
68 |     {% if page.resolution != undefined %}
69 |     <tr>
70 |       <th>Resolution</th>
71 |       <td><a href="{{page.resolution | uri_escape }}">{{ page.resolution | xml_escape }}</a></td>
72 |     </tr>
73 |     {% endif %}
74 |   </table>
75 | 
76 |   {{ content }}
77 | 
78 | </div>


--------------------------------------------------------------------------------
/assets/main.scss:
--------------------------------------------------------------------------------
  1 | ---
  2 | ---
  3 | 
  4 | @import "{{ site.theme }}";
  5 | @import url('https://fonts.googleapis.com/css?family=Montserrat');
  6 | 
  7 | 
  8 | .wrapper {
  9 |     position: relative;
 10 |     max-width: -webkit-calc(960px - (30px * 2));
 11 |     max-width: calc(960px - (30px * 2));
 12 | }
 13 | .uk-position-top-left {
 14 |     top: 0.7rem;
 15 |     left: 30px;
 16 |     position: absolute;
 17 | }
 18 | .site-nav {
 19 |     z-index: 100; 
 20 | }
 21 | .uk-adm-logo {
 22 |     border: solid #eee;
 23 |     border-width: 1px;
 24 |     background: rgba(255, 255, 255, 1);
 25 |     z-index: 1000;
 26 |     position: relative;
 27 |     box-shadow: 0 3px 10px rgba(0, 0, 0, 0.1);
 28 |     border-radius: 50%;
 29 |     display: block;
 30 | }
 31 | .uk-adm-logo:hover {
 32 |     box-shadow: 0 0px 3px rgba(0, 0, 0, 0.1);
 33 | }
 34 | .site-title {
 35 |     float: right;
 36 | }
 37 | .site-header {
 38 |     padding-top: 20px;
 39 | }
 40 | .uk-responsive-height {
 41 |     max-height: 100%;
 42 |     width: auto;
 43 |     max-width: none;
 44 |     width: 78px;
 45 | }
 46 | body {
 47 |     background-color: white;
 48 |     background-image: url("data:image/svg+xml,%3Csvg width='6' height='6' viewBox='0 0 6 6' xmlns='http://www.w3.org/2000/svg'%3E%3Cg fill='%23eeeeee' fill-opacity='1' fill-rule='evenodd'%3E%3Cpath d='M5 0h1L0 6V5zM6 5v1H5z'/%3E%3C/g%3E%3C/svg%3E");
 49 |     font-family: 'Montserrat', sans-serif;
 50 | }
 51 | 
 52 | .uk-list {
 53 |     list-style: none;
 54 |     margin-left:0;
 55 | }
 56 | .uk-list-footer li {
 57 |     line-height: 40px;
 58 |     white-space: nowrap;
 59 | 
 60 | }
 61 | 
 62 | .uk-child-width-expand>:not([class*=uk-width]) {
 63 |     flex: 1;
 64 |     min-width: 0;
 65 |     flex-basis: 1px;
 66 | }
 67 | .uk-width-auto {
 68 |     width: auto;
 69 | }
 70 | [class*=uk-width] {
 71 |     box-sizing: border-box;
 72 |     width: 100%;
 73 |     max-width: 100%;
 74 | }
 75 | .uk-child-width-expand>* {
 76 |     width: 1px;
 77 | }
 78 | .uk-first-column {
 79 |     float: left;
 80 |     width: auto!important;
 81 |     padding-right: 1rem;
 82 |     max-height: 40px;
 83 | }
 84 | .uk-first-column svg {
 85 |     vertical-align:middle;
 86 | }
 87 | .footer-col-1 {
 88 |     width: -webkit-calc(50% - (30px / 2));
 89 |     width: calc(50% - (30px / 2));
 90 | }
 91 | [class*=uk-child-width]>* {
 92 |     box-sizing: border-box;
 93 |     width: 100%;
 94 | }
 95 | .uk-grid-small>* {
 96 |     padding-left: 20px;
 97 | }
 98 | 
 99 | @media screen and (max-width: 600px) {
100 |     .uk-position-top-left {
101 |         display:none;
102 |     }
103 |     .site-title {
104 |         float:left;
105 |     }
106 | }
107 | 


--------------------------------------------------------------------------------
/AIPS/aip-6.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 6
 3 | title: Signal Messages
 4 | author: Dmitriy Soloduhin (@zyuhel)
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/9
 6 | status: Accepted
 7 | type: Standards
 8 | category: ARC
 9 | created: 2018-06-09
10 | requires: 4
11 | 
12 | ---
13 | 
14 | Hidden (system) messages for different services.
15 | 
16 | ## Abstract
17 | <!--A short (~200 word) description of the technical issue being addressed.-->
18 | Sometimes it is needed to send encrypted messages, that shouldn't appear in chats (hidden). This system messages will be called Signals. Signals should be used for User-Service or Service-Service communications. Example is [Register for Push notifications message](https://medium.com/adamant-im/adamant-is-working-on-blockchain-messaging-platform-and-push-notifications-service-765972cce50e).
19 | 
20 | ## Specification
21 | 
22 | Signal messages follows encryption algorithm defined in [AIP-4](https://aips.adamant.im/AIPS/aip-4).
23 | Chat `type` of signal messages is `3`. This chat type should not be returned on chat endpoints on any compliant node, unless request for this chat type is forced by corresponding filter.
24 | 
25 | Clients should not make be this messages visible in dialogs.
26 | 
27 | ## Syntax
28 | 
29 | Structure of transaction `asset`:
30 | 
31 | ````
32 | chat: {
33 |   message: "HEXIFIED_ENCRYPTED_MESSAGE"
34 |   own_message: "HEXIFIED_NONCE"
35 |   type: 3
36 | }
37 | ````
38 | 
39 | ### Examples
40 | 
41 | ```` json
42 | {
43 |   "transaction": {
44 |     "type": 8,
45 |     "amount": 0,
46 |     "senderId": "U15677078342684640219",
47 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a043...",
48 |     "asset": {
49 |       "chat": {
50 |         "message": "70cbd07ff2ceaf0fc38a01ef9...",
51 |         "own_message": "e98794eaedf47e...",
52 |         "type": 3
53 |       }
54 |     },
55 |     "recipientId": "U10629337621822775991",
56 |     "timestamp": 46116887,
57 |     "signature": "8fc2a54604109a6fcdccec2..."
58 |   }
59 | }
60 | 
61 | ````
62 | 
63 | Subscribes user iOS device for Push notifications. U10629337621822775991 is general iOS [Push Notification Service](https://github.com/Adamant-im/adamant-notificationService) address.
64 | 
65 | ## Rationale
66 | 
67 | Some sort of client-service communication is needed for internal processes, such as Push server registration. This process should take place on ADAMANT network itself, instead of relying of some third party transfer medium. This type of messages should follow all security guidelines, and must not disturb users with technic data.
68 | 
69 | ## Copyright
70 | 
71 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
72 | 


--------------------------------------------------------------------------------
/AIPS/aip-5.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 5
 3 | title: Rich Content Messages
 4 | author: Dmitriy Soloduhin (@zyuhel)
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/8
 6 | status: Accepted
 7 | type: Standards
 8 | category: ARC
 9 | created: 2018-06-09
10 | requires: 4
11 | ---
12 | 
13 | Exchanging Rich Content Messages across different clients.
14 | 
15 | ## Simple Summary
16 | 
17 | Extending messages with Flexible Rich Content.
18 | 
19 | ## Abstract
20 | 
21 | Define a specification of Rich Content messages, so that various clients can handle them.
22 | 
23 | ## Specification
24 | 
25 | Rich messages are encrypted as specified in [AIP-4](https://aips.adamant.im/AIPS/aip-4).
26 | 
27 | To mark message as Rich text, put `2` value in `type` field of transaction `asset`.
28 | 
29 | Rich Message must be a JSON object, sent within `message` field of transaction `asset`. It required to have `type` field with string value, describing how to handle it. Additional AIPs should be created for different Rich Text `type` handlers. Optional field `text_fallback` can be added to show explanation text messages on clients that doesn't support this Message Type.
30 | 
31 | Rich messages should be shown in chat streams as ordinary messages, but their content, and theirs rendering process will be defined by corresponding Rich Message `type`.
32 | 
33 | Clients shouldn't render unsupported or unknown message types, instead they must show a message about unsupported rich message type and/or text fallback if it is available.
34 | 
35 | ## Syntax
36 | 
37 | Structure of transaction `asset`:
38 | 
39 | ````
40 | chat: {
41 |   message: "HEXIFIED_ENCRYPTED_MESSAGE"
42 |   own_message: "HEXIFIED_NONCE"
43 |   type: 2
44 | }
45 | ````
46 | 
47 | Field `message` should contain encrypted JSON of Rich Text. Below shown a base structure of Rich Text JSON object. It may have any other fields, only `type` field is required.
48 | 
49 | ````
50 | {
51 |   type: "RICH_MESSAGE_TYPE",
52 |   text_fallback: "OPTIONAL_FALLBACK_FOR_CLIENTS_NOT_SUPPORTING_THIS_MESSAGE_TYPE"
53 | }
54 | ````
55 | 
56 | ### Examples
57 | 
58 | ```` json
59 | {
60 |   "transaction": {
61 |     "type": 8,
62 |     "amount": 0,
63 |     "senderId": "U15677078342684640219",
64 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
65 |     "asset": {
66 |       "chat": {
67 |         "message": "70cbd07ff2ceaf0fc38a01ef9...",
68 |         "own_message": "e98794eaedf47e...",
69 |         "type": 2
70 |       }
71 |     },
72 |     "recipientId": "U7972131227889954319",
73 |     "timestamp": 46116887,
74 |     "signature": "8fc2a54604109a6fcdccec2..."
75 |   }
76 | }
77 | ````
78 | 
79 | Sends Rich message describing In-Chat Ether transfer.
80 | 
81 | ## Rationale
82 | 
83 | Rich messages, such as different objects/ media / crypto transfers, should be handled in same way between different clients.
84 | 
85 | ## Copyright
86 | 
87 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
88 | 


--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
 1 | ---
 2 | layout: default
 3 | title: Home
 4 | ---
 5 | 
 6 | <h1 class="page-heading">AIPs </h1>
 7 | <p>ADAMANT Improvement Proposals (AIPs) describe standards for the ADAMANT Messenger platform, including core protocol specifications, and client APIs.</p>
 8 | 
 9 | <h2>Contributing</h2>
10 | <p>First review <a href="AIPS/aip-1">AIP-1</a>. Then clone the repository and add your AIP to it. There is a <a href="https://github.com/Adamant-im/AIPs/blob/master/aip-X.md">template AIP here</a>. Then submit a Pull Request to ADAMANT's <a href="https://github.com/Adamant-im/AIPs">AIPs repository</a>.</p>
11 | 
12 | <h2>AIP status terms</h2>
13 | <ul>
14 |   <li><strong>Draft</strong>: an AIP that is open for consideration</li>
15 |   <li><strong>Accepted</strong>: an AIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork</li>
16 |   <li><strong>Final</strong>: an AIP that has been adopted in a previous hard fork</li>
17 |   <li><strong>Deferred</strong>: an AIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork</li>
18 | </ul>
19 | 
20 | <h2>AIP Types</h2>
21 | 
22 | <p>AIPs are separated into a number of types, and each has its own list of AIPs.</p>
23 | 
24 | <h3>Standard ({{site.pages|where:"type","Standards"|size}})</h3>
25 | 
26 | <h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards"|where:"category","Core"|size}})</h4>
27 | <p>Improvements requiring a node update.</p>
28 | 
29 | <h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards"|where:"category","Networking"|size}})</h4>
30 | <p>Internode communications updates.</p>
31 | 
32 | <h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards"|where:"category","Interface"|size}})</h4>
33 | <p>Includes improvements around client API/RPC specifications and standards.</p>
34 | 
35 | <h4><a href="{{"api"|relative_url}}">API</a> ({{site.pages|where:"type","Standards"|where:"category","API"|size}})</h4>
36 | <p>API endpoint specifications.</p>
37 | 
38 | <h4><a href="{{"arc"|relative_url}}">ARC</a> ({{site.pages|where:"type","Standards"|where:"category","ARC"|size}})</h4>
39 | <p>Application-level standards and conventions, including URI schemes, library/package formats, and wallet formats.</p>
40 | 
41 | <h3><a href="{{"informational"|relative_url}}">Informational</a> ({{site.pages|where:"type","Informational"|size}})</h3>
42 | <p>Describes an ADAMANT design issue, or provides general guidelines or information to the  community, but does not propose a new feature. Informational AIPs do not necessarily represent  community consensus or a recommendation, so users and implementers are free to ignore Informational AIPs or follow their advice.</p>
43 | 
44 | <h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3>
45 | <p>Describes a process surrounding ADAMANT or proposes a change to (or an event in) a process. </p>
46 | 


--------------------------------------------------------------------------------
/AIPS/aip-9.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 9
 3 | title: URI Format for ADAMANT
 4 | author: Aleksei Lebedev
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/19
 6 | status: Accepted
 7 | extends: 2
 8 | type: Standards
 9 | category: ARC
10 | created: 2019-02-12
11 | ---
12 | 
13 | <!--You can leave these HTML comments in your merged AIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
14 | 
15 | ## Simple Summary
16 | 
17 | A standard way of creating ADAMANT URIs for various use-cases.
18 | 
19 | ## Abstract
20 | <!--A short (~200 word) description of the technical issue being addressed.-->
21 | This AIP extends [AIP-2](https://aips.adamant.im/AIPS/aip-2) and adds new parameters.
22 | 
23 | ## Motivation
24 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
25 | Propose parameters to include in URI actions and their parameters. Standartise QR-codes between different ADAMANT Messenger realizations.
26 | 
27 | ## Specification
28 | 
29 | URI can contain optional `parameters`:
30 | 
31 | - `label` is a contact name as in [AIP-2](https://aips.adamant.im/AIPS/aip-2). If address has no name in KVS address book yet, app should name it.
32 | - `amount` is amount in ADM to send
33 | - `message` is a message which supposed to be sent to contact (or as a comment for a transfer)
34 | 
35 | It is up to application how to process parameters, it depends when user retrieves URL in the app. F. e., in In-Chat Send tokens screen, it can parse `amount` and `message` values.
36 | 
37 | ### Examples
38 | 
39 | ```
40 | adm:U9821606738809290000?label=John+Doe&message=Just+say+hello
41 | ```
42 | 
43 | App adds chat with U9821606738809290000, name him as "John Doe" if he is not named yet, and put message "Just say hello" to input field ready to send.
44 | 
45 | ```
46 | adm:U9821606738809290000?label=John+Doe&amount=1.12&message=Buy+a+beer
47 | ```
48 | 
49 | If user read this string from QR in Send Tokens screen, app fills `to` field with U9821606738809290000, `amount` with 1.12 ADM, and `comment` with "Buy a beer".
50 | If app processes this string that received from outside, it adds chat with U9821606738809290000, name him as "John Doe" if he is not named yet, and put message "Buy a beer".
51 | 
52 | ## Rationale
53 | <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
54 | Parameters allows to extend possibilities included in URIs, like in QR codes.
55 | 
56 | ## Copyright
57 | 
58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
59 | 


--------------------------------------------------------------------------------
/AIPS/aip-2.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 2
 3 | title: URI Format for ADAMANT
 4 | author: Dmitriy Soloduhin (@zyuhel), Pavel Anokhov (@RealBonus)
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/2
 6 | status: Accepted
 7 | type: Standards
 8 | category: ARC
 9 | created: 2018-05-02
10 | ---
11 | 
12 | <!--You can leave these HTML comments in your merged AIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
13 | 
14 | ## Simple Summary
15 | 
16 | A standard way of creating ADAMANT URIs for various use-cases.
17 | 
18 | ## Abstract
19 | <!--A short (~200 word) description of the technical issue being addressed.-->
20 | URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URI format allows for instant invocation of the user’s preferred wallet application and simplifies usage.
21 | 
22 | ## Motivation
23 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
24 | Help integrating ADAMANT into the World. Standartise QR-codes between different ADAMANT Messenger realizations.
25 | 
26 | ## Specification
27 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
28 | ### Syntax
29 | 
30 | ADAMANT URIs contain "adm" in their schema (protocol) part and are constructed as follows:
31 | 
32 | ```
33 | request                 = "adm" ":" address [?parameters]
34 | address                 = string
35 | parameters              = (argument=value[&])*
36 | argument                = uri encoded string
37 | value                   = uri encoded string
38 | ```
39 | 
40 | ### Semantics
41 | 
42 | `address` is mandatory and starts with U letter. It should follow ADAMANT address format.
43 | 
44 | `parameters` is optional argument-value pairs and defines specific actions to be done with following address. Some specifications should follow in consecutive ARCs.
45 | 
46 | Commonly known parameters:
47 | 
48 | - `label` is a contact name. Often used on business cards.
49 | 
50 | ### Examples
51 | 
52 | ```
53 | adm:U9821606738809290000?label=John+Doe
54 | ```
55 | 
56 | ## Rationale
57 | <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
58 | This ARC is needed to ensure that all ADAMANT Messengers realizations support same URI format.
59 | 
60 | ## Copyright
61 | 
62 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
63 | 


--------------------------------------------------------------------------------
/AIPS/aip-11.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 11
 3 | title: Behavior for KVS data
 4 | author: Aleksei Lebedev
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/27
 6 | requires: 3
 7 | extends: https://aips.adamant.im/AIPS/aip-3
 8 | status: Draft
 9 | type: Standards
10 | category: ARC
11 | created: 2019-02-18
12 | ---
13 | 
14 | ## Simple Summary
15 | 
16 | Describes how clients should process stored data for different content, allowing to write and read it faster.
17 | 
18 | ## Abstract
19 | <!--A short (~200 word) description of the technical issue being addressed.-->
20 | As [AIP-3](https://aips.adamant.im/AIPS/aip-3) stands, users save its public and private information in ADAMANT blockchain. To write and read it faster and cheaper, different types of records should be introduced, including full re-write and incremental.
21 | 
22 | ## Specification
23 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
24 | 
25 | When sending KVS transaction, `type` field of `state` object must be as follows:
26 | 
27 | - `0` for full re-writing of contents by specified `key` value
28 | - `1` for incremental appending contents
29 | 
30 | Client apps should decide wether to use `0` or `1` write type by themselves. It depends on content type `key`, and volume of updated information. For example, if user updates one's contact name, it is faster and cheaper to store only updated record with `1` type. When significant quantity of contact names updated, it is reasonable to re-write all of contact list with single store transaction with `0` type.
31 | 
32 | Nodes API should process KVS properly. Values `type` and `key` are public, so node must filter and return KVS records on client's demand. This will reduce traffic and processing time. For every `key` value, node must return latest transactions with `0` type, following updates with `1` type.
33 | 
34 | Client app should process received KVS records in reasonable way.
35 | 
36 | ### Examples
37 | 
38 | ``` json
39 | { 
40 |   "transaction": {
41 |     "type": 9,
42 |     "amount": 0,
43 |     "senderId": "U15677078342684640219",
44 |     "senderPublicKey": "e16e624fd0...",
45 |     "asset": {
46 |       "state": {
47 |         "key": "contact_list",
48 |         "value":"{
49 |           \"message\": \"6df8c172feef228d930130...\",
50 |           \"nonce\": \"f6c7b76d55db945bb026cd221d5...\"}",
51 |         "type": 0
52 |       }
53 |     },
54 |     "timestamp": 45603645,
55 |     "signature": "dbafce549f1..."
56 |   }
57 | }
58 | ```
59 | 
60 | Sends private (encrypted) full contact list for U15677078342684640219.
61 | 
62 | ``` json
63 | { 
64 |   "transaction": {
65 |     "type": 9,
66 |     "amount": 0,
67 |     "senderId": "U15677078342684640219",
68 |     "senderPublicKey": "e16e624fd0...",
69 |     "asset": {
70 |       "state": {
71 |         "key": "contact_list",
72 |         "value":"{
73 |           \"message\": \"6df8c172feef228d930130...\",
74 |           \"nonce\": \"f6c7b76d55db945bb026cd221d5...\"}",
75 |         "type": 1
76 |       }
77 |     },
78 |     "timestamp": 45603645,
79 |     "signature": "dbafce549f1..."
80 |   }
81 | }
82 | ```
83 | 
84 | Sends private (encrypted) updated contact records for U15677078342684640219.
85 | 
86 | ## Rationale
87 | 
88 | Using `type` of storing and reading KVS offers performance upgrade for client apps.
89 | 
90 | ## Copyright
91 | 
92 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
93 | 


--------------------------------------------------------------------------------
/AIPS/aip-4.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 4
  3 | title: Basic Encrypted Messages
  4 | author: Dmitriy Soloduhin (@zyuhel), Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/7
  6 | requires: 10
  7 | status: Accepted
  8 | type: Standards
  9 | category: ARC
 10 | created: 2018-06-09
 11 | ---
 12 | 
 13 | Structure of basic encrypted messages in ADAMANT.
 14 | 
 15 | ## Simple Summary
 16 | 
 17 | Describing current structure of basic encrypted ADAMANT messages, so that extensions or alternative clients can rely on it.
 18 | 
 19 | ## Abstract
 20 | <!--A short (~200 word) description of the technical issue being addressed.-->
 21 | To standartize message exchange between different ADAMANT clients we need to describe how messages are stored and encrypted/decrypted.
 22 | 
 23 | ## Specification
 24 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
 25 | Secure Message exchange is the base of ADAMANT messaging system.
 26 | 
 27 | Messages are encrypted using curve25519xsalsa20poly1305 ([NaCl box](https://nacl.cr.yp.to/box.html)) algorithm. Box is created using sender's private key and recipient's public key. Recipient's public key is retrieved from network.
 28 | 
 29 | Private and public keys of account are instances of Ed25519 signing keys, so they should be converted into Curve25519 Diffie-Hellman keys first.
 30 | 
 31 | ## Syntax
 32 | 
 33 | Transaction syntax is based on [AIP-10: General transaction structure](https://aips.adamant.im/AIPS/aip-10). Messaging blockchain transaction type is `8`.
 34 | 
 35 | Here is transaction `asset` contents syntax:
 36 | 
 37 | ````
 38 | chat: {
 39 |   message: HEXIFIED_ENCRYPTED_MESSAGE
 40 |   own_message: HEXIFIED_NONCE
 41 |   type: 1
 42 | }
 43 | ````
 44 | 
 45 | Value of chat `type` is `1` for basic encrypted message. For other types of messages should be described in future APIs.
 46 | 
 47 | ### Examples
 48 | 
 49 | ```json
 50 | {
 51 |   "transaction": {
 52 |     "type": 8,
 53 |     "amount": 0,
 54 |     "senderId": "U15677078342684640219",
 55 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07...",
 56 |     "asset": {
 57 |       "chat": {
 58 |         "message": "4bf88eb80f4710e5aec4...",
 59 |         "own_message": "9dded63b476e75a146e3f...",
 60 |         "type": 1
 61 |       }
 62 |     },
 63 |     "recipientId": "U7972131227889954319",
 64 |     "timestamp": 46115307,
 65 |     "signature": "aa468db9b70b731931308f7c7d0d1..."
 66 |   }
 67 | }
 68 | ```
 69 | 
 70 | Sends message to U7972131227889954319.
 71 | 
 72 | ```json
 73 | {
 74 |   "transaction": {
 75 |     "type": 8,
 76 |     "amount": 49000000,
 77 |     "senderId": "U15677078342684640219",
 78 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07...",
 79 |     "asset": {
 80 |       "chat": {
 81 |         "message": "4bf88eb80f4710e5aec4...",
 82 |         "own_message": "9dded63b476e75a146e3f...",
 83 |         "type": 1
 84 |       }
 85 |     },
 86 |     "recipientId": "U7972131227889954319",
 87 |     "timestamp": 46115307,
 88 |     "signature": "aa468db9b70b731931308f7c7d0d1..."
 89 |   }
 90 | }
 91 | ```
 92 | 
 93 | Transfer of 0.49 ADM to U7972131227889954319 with comment.
 94 | 
 95 | ## Rationale
 96 | 
 97 | Currently used mechanisms should also be documented, to make process of extending and updating clearer.
 98 | 
 99 | ## Copyright
100 | 
101 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
102 | 


--------------------------------------------------------------------------------
/_includes/social.html:
--------------------------------------------------------------------------------
 1 | <ul class="social-media-list">
 2 |   {%- if site.dribbble_username -%}<li><a href="https://dribbble.com/{{ site.dribbble_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#dribbble' | relative_url }}"></use></svg> <span class="username">{{ site.dribbble_username| escape }}</span></a></li>{%- endif -%}
 3 |   {%- if site.facebook_username -%}<li><a href="https://www.facebook.com/{{ site.facebook_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#facebook' | relative_url }}"></use></svg> <span class="username">{{ site.facebook_username| escape }}</span></a></li>{%- endif -%}
 4 |   {%- if site.flickr_username -%}<li><a href="https://www.flickr.com/photos/{{ site.flickr_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#flickr' | relative_url }}"></use></svg> <span class="username">{{ site.flickr_username| escape }}</span></a></li>{%- endif -%}
 5 |   <li><a href="https://github.com/Adamant-im/AIPs"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#github' | relative_url }}"></use></svg> <span class="username">Adamant-im/AIPs</span></a></li>
 6 |   {%- if site.instagram_username -%}<li><a href="https://instagram.com/{{ site.instagram_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#instagram' | relative_url }}"></use></svg> <span class="username">{{ site.instagram_username| escape }}</span></a></li>{%- endif -%}
 7 |   {%- if site.linkedin_username -%}<li><a href="https://www.linkedin.com/in/{{ site.linkedin_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#linkedin' | relative_url }}"></use></svg> <span class="username">{{ site.linkedin_username| escape }}</span></a></li>{%- endif -%}
 8 |   {%- if site.pinterest_username -%}<li><a href="https://www.pinterest.com/{{ site.pinterest_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#pinterest' | relative_url }}"></use></svg> <span class="username">{{ site.pinterest_username| escape }}</span></a></li>{%- endif -%}
 9 |   {%- for mst in site.mastodon -%}{%- if mst.username and mst.instance -%}<li><a href="https://{{ mst.instance| cgi_escape | escape}}/@{{mst.username}}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#mastodon' | relative_url }}"></use></svg> <span class="username">{{ mst.username|escape }}</span></a></li>{%- endif -%}{%- endfor -%}
10 |   {%- if site.twitter_username -%}<li><a href="https://www.twitter.com/{{ site.twitter_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#twitter' | relative_url }}"></use></svg> <span class="username">{{ site.twitter_username| escape }}</span></a></li>{%- endif -%}
11 |   {%- if site.youtube_username -%}<li><a href="https://youtube.com/{{ site.youtube_username| cgi_escape | escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#youtube' | relative_url }}"></use></svg> <span class="username">{{ site.youtube_username| escape }}</span></a></li>{%- endif -%}
12 |   {%- if site.googleplus_username -%}<li><a href="https://plus.google.com/{{ site.googleplus_username| escape }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#googleplus' | relative_url }}"></use></svg> <span class="username">{{ site.googleplus_username| escape }}</span></a></li>{%- endif -%}
13 |   {%- if site.rss -%}<li><a href="{{ 'feed.xml' | relative_url }}"><svg class="svg-icon"><use xlink:href="{{ '/assets/minima-social-icons.svg#rss' | relative_url }}"></use></svg> <span>{{ site.rss | escape }}</span></a></li>{%- endif -%}
14 | </ul>
15 | 


--------------------------------------------------------------------------------
/AIPS/aip-17.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 17
  3 | title: Reactions to Messages
  4 | author: Aleksei Lebedev (@adamant-al), Stanislav Jelezoglo (@StanislavDevIOS)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/52
  6 | requires: 5
  7 | extends: https://aips.adamant.im/AIPS/aip-5
  8 | status: Accepted
  9 | type: Standards
 10 | category: ARC
 11 | created: 2023-05-24
 12 | ---
 13 | 
 14 | ## Simple Summary
 15 | 
 16 | This proposal introduces the ability to add reactions to messages in ADAMANT Messenger apps.
 17 | 
 18 | ## Abstract
 19 | 
 20 | Reactions are represented as emoji-based responses to specific messages, enhancing the interactive and expressive capabilities of the messaging platform.
 21 | 
 22 | ## Motivation
 23 | 
 24 | To establish a consistent and standardized approach for implementing message reactions in ADAMANT Messenger apps, a comprehensive specification is necessary.
 25 | 
 26 | ## Specification
 27 | 
 28 | When a user wishes to react to a specific message, the client must send the ADM rich message as described in [AIP-5](https://aips.adamant.im/AIPS/aip-5) and include a new field called `reactto_id` in the message structure. See the syntax below.
 29 | 
 30 | ## Syntax
 31 | 
 32 | According to AIP-5, the field `transaction.asset.chat.message` must contain *encrypted stringified* JSON. For reactions, this JSON includes `reactto_id` and `react_message`, representing the chosen emoji reaction.
 33 | 
 34 | Below is the structure of the `message` object:
 35 | 
 36 | ````
 37 | {
 38 |   reactto_id: String
 39 |   react_message: String
 40 | }
 41 | ````
 42 | 
 43 | Object's fields as described:
 44 | 
 45 | - `reactto_id` — Represents the ADM transaction ID of the message to which the user is reacting. This field is mandatory.
 46 | - `react_message` — Denotes the chosen emoji reaction. This field is also mandatory.
 47 | 
 48 | Users can attach multiple reactions to a single message, *with each new reaction replacing the previous one*. A user's reaction to a specific message will be `react_message` with the latest tx `timestamp`. To remove a reaction, users can send an empty value for the `react_message` field:
 49 | 
 50 | ```` json
 51 | {
 52 |   "reactto_id": "7452709338464950789",
 53 |   "react_message": ""
 54 | }
 55 | ````
 56 | 
 57 | In a dialog, both participants can react to the same message, and an app will show both of them. How to display them is at the discretion of the application.
 58 | 
 59 | Reaction transaction is always a message, type `8`. See [AIP-10](https://aips.adamant.im/AIPS/aip-10#transaction-types)
 60 | 
 61 | ### Examples
 62 | 
 63 | Object `transaction.asset.chat.message` *before encryption*, sending reaction to a message:
 64 | 
 65 | ```` json
 66 | {
 67 |   "reactto_id": "7452709338464950789",
 68 |   "react_message": "👍"
 69 | }
 70 | ````
 71 | 
 72 | Example of removing a reaction:
 73 | 
 74 | ```` json
 75 | {
 76 |   "reactto_id": "7452709338464950789",
 77 |   "react_message": ""
 78 | }
 79 | ````
 80 | 
 81 | Full transaction after encryption from U15677078342684640219 to U7972131227889954319 looks like:
 82 | 
 83 | ```` json
 84 | {
 85 |   "transaction": {
 86 |     "type": 8,
 87 |     "amount": 0, // Amount should be 0
 88 |     "senderId": "U15677078342684640219",
 89 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
 90 |     "asset": {
 91 |       "chat": {
 92 |         "message": "70cbd07ff2ceaf0fc38a01ef9...", // `reactto_id` and `react_message` encrypted
 93 |         "own_message": "e98794eaedf47e...",
 94 |         "type": 2 // Type should be 2 (Rich Content Message)
 95 |       }
 96 |     },
 97 |     "recipientId": "U7972131227889954319",
 98 |     "timestamp": 46116887,
 99 |     "signature": "8fc2a54604109a6fcdccec2..."
100 |   }
101 | }
102 | ````
103 | 
104 | ## Rationale
105 | 
106 | The introduction of reactions adds a layer of interactivity and engagement to ADAMANT Messenger, allowing users to express sentiments quickly without the need for extensive text-based replies. A standardized approach ensures consistent behavior across different ADAMANT Messenger apps.
107 | 
108 | ## Copyright
109 | 
110 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
111 | 


--------------------------------------------------------------------------------
/AIPS/aip-8.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: 8
 3 | title: URI Format for ADAMANT
 4 | author: Aleksei Lebedev
 5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/16
 6 | extends: https://aips.adamant.im/AIPS/aip-2
 7 | status: Accepted
 8 | type: Standards
 9 | category: ARC
10 | created: 2019-02-12
11 | ---
12 | 
13 | <!--You can leave these HTML comments in your merged AIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
14 | 
15 | ## Simple Summary
16 | 
17 | How to create and process URIs, which includes ADAMANT contacts and actions.
18 | 
19 | ## Abstract
20 | <!--A short (~200 word) description of the technical issue being addressed.-->
21 | URIs embedded in QR-codes, web-pages, emails or chat messages provide a way to create or open chat with specific contact and name it.
22 | 
23 | This AIP extends [AIP-2](https://aips.adamant.im/AIPS/aip-2). AIP-8 is a preferred URI format for ADAMANT addresses in QR codes. All types of ADAMANT apps should read both types of URI, but generate URI only as AIP-8 explains.
24 | 
25 | ## Motivation
26 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
27 | Current URI format [AIP-2](https://aips.adamant.im/AIPS/aip-2) is not suitable for people who are not familiar with ADAMANT and don't use ADAMANT apps yet. Using this extension helps new users to contact friends in ADAMANT, and existing users can share their ADAMANT address easily.
28 | 
29 | So if QR with URI is scanned in general QR scanner app, it will open web app, but if QR is scanned from ADAMANT app, address can be parsed.
30 | 
31 | ## Specification
32 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
33 | ### Syntax
34 | 
35 | ADAMANT URIs may contain `address` in their parameters as follows:
36 | 
37 | ```
38 | web app URI             = web link [?parameters]
39 | parameters              = (argument=value[&])*
40 | argument                = uri encoded string
41 | value                   = uri encoded string
42 | ```
43 | 
44 | ### Semantics
45 | 
46 | `parameters` is optional argument-value pairs and defines specific actions to be done with following address.
47 | 
48 | Commonly known parameters:
49 | 
50 | - `address` is a valid ADAMANT address, starts with U letter.
51 | 
52 | If `address` parameter included, other parameters can be used according to as [AIP-2](https://aips.adamant.im/AIPS/aip-2#semantics).
53 | 
54 | ### Web app behaviour specifics
55 | 
56 | Supposed scenarios for web apps for processing URIs:
57 | 
58 | - If parameters can't be processed, ignore them
59 | - User can be logged in Messenger, or not. Anyway, after log in or creating new ADAMANT account, URI should be processed.
60 | - If `address` is an existing contact, go to chat window with him. If contact has no name in KVS address book yet, name it with `label` parameter.
61 | - If `address` is a new contact, create chat with him and name him as `label`
62 | 
63 | ### Other apps behaviour specifics
64 | 
65 | iOS and Android apps should only read parameters from URIs.
66 | 
67 | ### Examples
68 | 
69 | ```
70 | https://msg.adamant.im?address=U9821606738809290000&label=John+Doe
71 | ```
72 | 
73 | Creates or open chat with U9821606738809290000. Name him as "John Doe" if contact is not named yet.
74 | 
75 | ## Rationale
76 | <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
77 | General web-links read by any QR code scanner and supported by any web browser. This allows to share ADM contacts easily.
78 | 
79 | ## Copyright
80 | 
81 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
82 | 


--------------------------------------------------------------------------------
/AIPS/aip-16.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 16
  3 | title: Quote/reply messages
  4 | author: Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/48
  6 | requires: 5
  7 | extends: https://aips.adamant.im/AIPS/aip-5
  8 | status: Accepted
  9 | type: Standards
 10 | category: ARC
 11 | created: 2022-02-18
 12 | ---
 13 | 
 14 | ## Simple Summary
 15 | 
 16 | Adds Quote/Reply-to-message possibility for ADAMANT Messenger apps.
 17 | 
 18 | ## Abstract
 19 | <!--A short (~200 word) description of the technical issue being addressed.-->
 20 | A message sent in reply to another message must be stored with the reply-to identifier.
 21 | 
 22 | ## Motivation
 23 | 
 24 | A standard is needed to ensure all ADAMANT Messenger apps interpret Quote/Reply-to messages in the same way.
 25 | 
 26 | ## Specification
 27 | 
 28 | When sending a message in reply to another message (quote), a client must send the ADM rich message as described in [AIP-5](https://aips.adamant.im/AIPS/aip-5) and include `replyto_id` field. See the syntax below.
 29 | 
 30 | A client that receives such a message can process it in different ways. A typical scenario:
 31 | 
 32 | - Decrypt a message (identified by `id`) and get `replyto_id`
 33 | - If `replyto_id` message (transaction) is not stored in a local database, fetch it from the blockchain and decrypt
 34 | - In chat, show message `id` with `replyto_id` message text as quoted
 35 | - Check if the local database stores all the message history since the `replyto_id` message, and fetch them, if not. It's important because there should be no gap between locally stored message and the `replyto_id` message.
 36 | - Click/tap quoted text: Scroll to `replyto_id` message
 37 | - Consider that the `replyto_id` message may not exist, or belongs to another sender, or is not decryptable
 38 | - Consider that the `replyto_id` message may be an ADM simple transfer
 39 | 
 40 | ## Syntax
 41 | 
 42 | According to AIP-5, field `transaction.asset.chat.message` must contain *encrypted stringified* JSON. For quote/reply, this JSON includes `replyto_id` and the message itself.
 43 | 
 44 | Below is the structure of the `message` object:
 45 | 
 46 | ````
 47 | {
 48 |   replyto_id: String
 49 |   reply_message: String
 50 | }
 51 | ````
 52 | 
 53 | Object's fields as described:
 54 | 
 55 | - `replyto_id` — ADM transaction ID of a message to which a user replies. Mandatory.
 56 | - `reply_message` — Text of a reply. It may include nested JSON (i. e. Crypto transfer). Mandatory.
 57 | 
 58 | Reply transaction is always a message, type `8`. See [AIP-10](https://aips.adamant.im/AIPS/aip-10#transaction-types). In case of `amount` > `0`, a reply is in-chat ADM transfer with comment.
 59 | 
 60 | ### Examples
 61 | 
 62 | Object `transaction.asset.chat.message` *before encryption*, sending "I've got it. Will be there in time." message in reply to 7452709338464950789 ADM transaction:
 63 | 
 64 | ```` json
 65 | {
 66 |   "replyto_id": "7452709338464950789",
 67 |   "reply_message": "I've got it. Will be there in time."
 68 | }
 69 | ````
 70 | 
 71 | Object `transaction.asset.chat.message` *before encryption*, sending 0.002 ETH in reply to 7452709338464950789 ADM transaction:
 72 | 
 73 | ```` json
 74 | {
 75 |   "replyto_id": "7452709338464950789",
 76 |   "reply_message": {
 77 |     "type": "eth_transaction",
 78 |     "amount": "0.002",
 79 |     "comments": "I like to send it, send it",
 80 |     "hash": "0xfa46d2b3c99878f1f9863fcbdb0bc27d220d7065c6528543cbb83ced84487deb"
 81 |   },
 82 | }
 83 | ````
 84 | 
 85 | Full transaction after encryption from U15677078342684640219 to U7972131227889954319 looks like:
 86 | 
 87 | ```` json
 88 | {
 89 |   "transaction": {
 90 |     "type": 8,
 91 |     "amount": 0, // In case of amount > 0, reply is in-chat ADM transfer with comment
 92 |     "senderId": "U15677078342684640219",
 93 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
 94 |     "asset": {
 95 |       "chat": {
 96 |         "message": "70cbd07ff2ceaf0fc38a01ef9...",
 97 |         "own_message": "e98794eaedf47e...",
 98 |         "type": 2 // 1 for Basic Encrypted Message
 99 |       }
100 |     },
101 |     "recipientId": "U7972131227889954319",
102 |     "timestamp": 46116887,
103 |     "signature": "8fc2a54604109a6fcdccec2..."
104 |   }
105 | }
106 | ````
107 | 
108 | ## Rationale
109 | 
110 | Quote/Reply-to messages must be handled in the same way across different clients.
111 | 
112 | ## Copyright
113 | 
114 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
115 | 


--------------------------------------------------------------------------------
/AIPS/aip-12.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 12
  3 | title: Non-ADM crypto transfer messages
  4 | author: Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/29
  6 | requires: 5
  7 | extends: https://aips.adamant.im/AIPS/aip-5
  8 | status: Accepted
  9 | type: Standards
 10 | category: ARC
 11 | created: 2019-02-20
 12 | ---
 13 | 
 14 | ## Simple Summary
 15 | 
 16 | Describes behaviour for transferring different coins/tokens in chats.
 17 | 
 18 | ## Abstract
 19 | <!--A short (~200 word) description of the technical issue being addressed.-->
 20 | Transferring external (non-ADM) tokens in chats is possible due to [public storage of wallet addresses in blockchain, AIP 13](https://aips.adamant.im/AIPS/aip-13).
 21 | 
 22 | As such transactions actually goes through own tokens' networks, special ADM messages needed to show them in chats.
 23 | 
 24 | ## Motivation
 25 | 
 26 | To make sure all ADAMANT Messenger apps process in-chats crypto transfers same way, a standard needed.
 27 | 
 28 | ## Specification
 29 | 
 30 | General way of making in-chat transfer:
 31 | 
 32 | - Send ADM rich message describing this transaction according to [AIP-5](https://aips.adamant.im/AIPS/aip-5). See syntax below.
 33 | - Send external token transaction in its own network
 34 | - Watch for external token transaction in its own network and update its status
 35 | 
 36 | Clients must support five types of transactions statuses both of incoming and outgoing transfers until final status reached:
 37 | 
 38 | - `Pending` — transaction just send, and a token node doesn't know it yet
 39 | - `Registered` — a token node replies a tx as registered, but not confirmed yet
 40 | - `Confirmed` — transaction is confirmed on token's network. Final status.
 41 | - `Cancelled` — transaction is cancelled or not accepted on token's network. Final status.
 42 | - `Inconsistent` — information about transaction, fetched from rich message in ADAMANT network, differs from information, fetched from token's network. It relies to amount, recipient and senders ids, and timestamp. Amount should be compared with meaningful accuracy (e. g., 0.00000001 Ether and 0.0000009998 Ether is the same). Timestamp should be compared with 24 hour accuracy. Final status.
 43 | 
 44 | Clients shouldn't render unsupported or unknown crypto transfers, instead they must show a message about unsupported rich message type and/or text fallback if it is available.
 45 | 
 46 | ## Syntax
 47 | 
 48 | Field `message` must contain *encrypted* JSON of transaction info, including ticker symbol, amount, comments and transaction id.
 49 | 
 50 | Below shown structure of `message` object:
 51 | 
 52 | ````
 53 | {
 54 |   type: String
 55 |   text_fallback: String
 56 |   amount: String
 57 |   comments: String
 58 |   hash: String
 59 | }
 60 | ````
 61 | 
 62 | Object's fields as described:
 63 | 
 64 | - `type` represents token's network and looks like `tickerSymbol_transaction`, e.g., `eth_transaction`. Ticker symbol must be in lower case, but apps must process it in any case for backwards compatibility. Mandatory.
 65 | - `amount` — transferred value in tokens of its network. Decimal separator is `.`. Mandatory.
 66 | - `comments` — optional, and may include comment for this transfer, shown to both recipient and sender.
 67 | - `hash` — transaction id in token's network. Used to check transaction status. Mandatory.
 68 | - `text_fallback` can be added to show explanation text messages on client apps that doesn't support specified `type`.
 69 | 
 70 | ### Examples
 71 | 
 72 | ````
 73 | {
 74 |   type: "eth_transaction"
 75 |   text_fallback: "OPTIONAL_FALLBACK_FOR_CLIENTS_NOT_SUPPORTING_THIS_MESSAGE_TYPE"
 76 |   amount: "0.002"
 77 |   comments: "I like to send it, send it"
 78 |   hash: "0xfa46d2b3c99878f1f9863fcbdb0bc27d220d7065c6528543cbb83ced84487deb"
 79 | }
 80 | ````
 81 | 
 82 | Object `message` *before encryption*, sending 0.002 Ethers with comment "I like to send it, send it".
 83 | 
 84 | ```` json
 85 | {
 86 |   "transaction": {
 87 |     "type": 8,
 88 |     "amount": 0,
 89 |     "senderId": "U15677078342684640219",
 90 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
 91 |     "asset": {
 92 |       "chat": {
 93 |         "message": "70cbd07ff2ceaf0fc38a01ef9...",
 94 |         "own_message": "e98794eaedf47e...",
 95 |         "type": 2
 96 |       }
 97 |     },
 98 |     "recipientId": "U7972131227889954319",
 99 |     "timestamp": 46116887,
100 |     "signature": "8fc2a54604109a6fcdccec2..."
101 |   }
102 | }
103 | ````
104 | 
105 | Sends Rich message describing In-Chat Ether transfer from U15677078342684640219 to U7972131227889954319.
106 | 
107 | ## Rationale
108 | 
109 | Crypto transfers must be handled in same way between different clients.
110 | 
111 | ## Copyright
112 | 
113 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
114 | 


--------------------------------------------------------------------------------
/aip-X.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | aip: <to be assigned>
 3 | title: <AIP title>
 4 | author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
 5 | discussions-to: <email address>
 6 | status: Draft
 7 | type: <Standards (Core, Networking, Interface, API, ARC)  | Informational | Meta>
 8 | category (*only required for Standard Track): <Core | Networking | Interface | API | ARC>
 9 | created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
10 | requires (*optional): <AIP number(s)>
11 | replaces (*optional): <AIP number(s)>
12 | ---
13 | 
14 | <!--You can leave these HTML comments in your merged AIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
15 | This is the suggested template for new AIPs.
16 | 
17 | Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`.
18 | 
19 | The title should be 44 characters or less.
20 | 
21 | ## Simple Summary
22 | <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the AIP.-->
23 | If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the AIP.
24 | 
25 | ## Abstract
26 | <!--A short (~200 word) description of the technical issue being addressed.-->
27 | A short (~200 word) description of the technical issue being addressed.
28 | 
29 | ## Motivation
30 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
31 | The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.
32 | 
33 | ## Specification
34 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
35 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.
36 | 
37 | ## Rationale
38 | <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
39 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
40 | 
41 | ## Backwards Compatibility
42 | <!--All AIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The AIP must explain how the author proposes to deal with these incompatibilities. AIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
43 | All AIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The AIP must explain how the author proposes to deal with these incompatibilities. AIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
44 | 
45 | ## Test Cases
46 | <!--Test cases for an implementation are mandatory for AIPs that are affecting consensus changes. Other AIPs can choose to include links to test cases if applicable.-->
47 | Test cases for an implementation are mandatory for AIPs that are affecting consensus changes. Other AIPs can choose to include links to test cases if applicable.
48 | 
49 | ## Implementation
50 | <!--The implementations must be completed before any AIP is given status "Final", but it need not be completed before the AIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
51 | The implementations must be completed before any AIP is given status "Final", but it need not be completed before the AIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.
52 | 
53 | ## Copyright
54 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
55 | 


--------------------------------------------------------------------------------
/_includes/footer.html:
--------------------------------------------------------------------------------
 1 | <footer class="site-footer h-card">
 2 |     <data class="u-url" href="{{ " /" | relative_url }}"></data>
 3 | 
 4 |     <div class="wrapper">
 5 | 
 6 |         <h2 class="footer-heading">{{ site.title | escape }}</h2>
 7 |         <div class="footer-col-wrapper">
 8 | 
 9 |             <div class="footer-col footer-col-1">
10 | 
11 |                 <ul class="uk-list-footer uk-list uk-scrollspy-inview uk-animation-fade" uk-scrollspy-class="" style="">
12 |                     <li class="el-item">
13 |                         <div class="uk-grid-small uk-child-width-expand uk-flex-nowrap uk-flex-middle uk-grid"
14 |                             uk-grid="">
15 |                             <div class="uk-width-auto uk-first-column">
16 |                                 <a href="https://adamant.im" class="uk-link-reset"><img
17 |                                         src="https://adamant.im/media/admwebsite.svg" class="el-image" alt="" width="20"
18 |                                         height="20"></a>
19 |                             </div>
20 |                             <div>
21 |                                 <div class="el-content">
22 |                                     <a href="https://adamant.im" target="_blank" class="el-link">ADAMANT Website</a>
23 |                                 </div>
24 |                             </div>
25 |                         </div>
26 |                     </li>
27 | 
28 | 
29 |                     <li class="el-item">
30 |                         <div class="uk-grid-small uk-child-width-expand uk-flex-nowrap uk-flex-middle uk-grid"
31 |                             uk-grid="">
32 |                             <div class="uk-width-auto uk-first-column">
33 |                                 <span uk-icon="icon: thumbnails" class="el-image uk-text-muted uk-icon"
34 |                                     style='vertical-align:top'><svg width="20" height="20" viewBox="0 0 20 20"
35 |                                         xmlns="http://www.w3.org/2000/svg" ratio="1">
36 |                                         <rect fill="none" stroke="#000" x="3.5" y="3.5" width="5" height="5"></rect>
37 |                                         <rect fill="none" stroke="#000" x="11.5" y="3.5" width="5" height="5"></rect>
38 |                                         <rect fill="none" stroke="#000" x="11.5" y="11.5" width="5" height="5"></rect>
39 |                                         <rect fill="none" stroke="#000" x="3.5" y="11.5" width="5" height="5"></rect>
40 |                                     </svg></span>
41 |                             </div>
42 |                             <div>
43 |                                 <div class="el-content">
44 |                                     <a class="" href="https://adamant.im/devs/" target="_blank">ADAMANT Dev Section</a>
45 |                                 </div>
46 |                             </div>
47 |                         </div>
48 |                     </li>
49 |                     <li class="el-item">
50 |                         <div class="uk-grid-small uk-child-width-expand uk-flex-nowrap uk-flex-middle uk-grid"
51 |                             uk-grid="">
52 |                             <div class="uk-width-auto uk-first-column">
53 |                                 <a href="https://github.com/adamant-im" class="uk-link-reset"><span
54 |                                         uk-icon="icon: github-alt" class="el-image uk-text-muted uk-icon"><svg
55 |                                             width="20" height="20" viewBox="0 0 20 20"
56 |                                             xmlns="http://www.w3.org/2000/svg" ratio="1">
57 |                                             <path
58 |                                                 d="M10,0.5 C4.75,0.5 0.5,4.76 0.5,10.01 C0.5,15.26 4.75,19.51 10,19.51 C15.24,19.51 19.5,15.26 19.5,10.01 C19.5,4.76 15.25,0.5 10,0.5 L10,0.5 Z M12.81,17.69 C12.81,17.69 12.81,17.7 12.79,17.69 C12.47,17.75 12.35,17.59 12.35,17.36 L12.35,16.17 C12.35,15.45 12.09,14.92 11.58,14.56 C12.2,14.51 12.77,14.39 13.26,14.21 C13.87,13.98 14.36,13.69 14.74,13.29 C15.42,12.59 15.76,11.55 15.76,10.17 C15.76,9.25 15.45,8.46 14.83,7.8 C15.1,7.08 15.07,6.29 14.75,5.44 L14.51,5.42 C14.34,5.4 14.06,5.46 13.67,5.61 C13.25,5.78 12.79,6.03 12.31,6.35 C11.55,6.16 10.81,6.05 10.09,6.05 C9.36,6.05 8.61,6.15 7.88,6.35 C7.28,5.96 6.75,5.68 6.26,5.54 C6.07,5.47 5.9,5.44 5.78,5.44 L5.42,5.44 C5.06,6.29 5.04,7.08 5.32,7.8 C4.7,8.46 4.4,9.25 4.4,10.17 C4.4,11.94 4.96,13.16 6.08,13.84 C6.53,14.13 7.05,14.32 7.69,14.43 C8.03,14.5 8.32,14.54 8.55,14.55 C8.07,14.89 7.82,15.42 7.82,16.16 L7.82,17.51 C7.8,17.69 7.7,17.8 7.51,17.8 C4.21,16.74 1.82,13.65 1.82,10.01 C1.82,5.5 5.49,1.83 10,1.83 C14.5,1.83 18.17,5.5 18.17,10.01 C18.18,13.53 15.94,16.54 12.81,17.69 L12.81,17.69 Z">
59 |                                             </path>
60 |                                         </svg></span></a>
61 |                             </div>
62 |                             <div>
63 |                                 <div class="el-content">
64 |                                     <a href="https://github.com/adamant-im" target="_blank" class="el-link"> ADAMANT on
65 |                                         GitHub</a>
66 |                                 </div>
67 |                             </div>
68 |                         </div>
69 |                     </li>
70 | 
71 |                 </ul>
72 | 
73 | 
74 |             </div>
75 | 
76 |             <div class="footer-col footer-col-3">
77 |                 <p>ADAMANT Improvement Proposals (AIPs) describe standards for the ADAMANT Messenger platform, including
78 |                     core protocol specifications and client APIs.</p>
79 |             </div>
80 | 
81 |         </div>
82 | 
83 |     </div>
84 | 
85 | </footer>


--------------------------------------------------------------------------------
/AIPS/aip-3.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 3
  3 | title: Storing data in chain (KVS)
  4 | author: Dmitriy Soloduhin (@zyuhel), Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/5
  6 | requires: 10
  7 | status: Accepted
  8 | type: Standards
  9 | category: ARC
 10 | created: 2018-05-19
 11 | updated: 2021-11-02
 12 | ---
 13 | 
 14 | Storing sensitive (encrypted) and shared (unencrypted) data in ADAMANT blockchain.
 15 | 
 16 | ## Simple Summary
 17 | 
 18 | Define ways of storing data in blockchain, so that different clients has understanding of how to handle it.
 19 | 
 20 | ## Abstract
 21 | <!--A short (~200 word) description of the technical issue being addressed.-->
 22 | Clients need to save different data across different devices. A standardized way of saving and retrieving data will help enhance user experience. Explanation and example of usage: [What is ‘Key-Value Store’ in ADAMANT and How is it used to Store Contact Names?](https://medium.com/adamant-im/what-is-key-value-store-in-adamant-and-how-is-it-used-to-store-contact-names-4ee5f82ab77f)
 23 | 
 24 | ## Specification
 25 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
 26 | Data storage should use State storing (KVS) functionality added in [v0.2.0 node release](https://github.com/Adamant-im/adamant/releases/tag/v0.2.0).
 27 | Selected key should be chosen according usage. If some key is going to be reused across different applications, corresponding AIP should be created, to ensure that all application will handle it similarly.
 28 | 
 29 | Unencrypted values are stored as-is, no additional actions are needed.
 30 | 
 31 | If a value needs to be encrypted, the following logic is to be applied:
 32 | 
 33 | 1. Wrap the value into JSON: ```{
 34 |   "payload": <your value>
 35 | }```
 36 | 2. Convert the above JSON to string; prefix and suffix the stringified JSON with a random string (alphanumeric ASCII-chars recommended; do not use `{` or `}`)
 37 | 3. Encrypt the resulting string using [NaCL.secretbox
 38 | ](https://nacl.cr.yp.to/secretbox.html). Secret key is a SHA-256 hash of the ADAMANT private key.
 39 | 4. Resulting nonce and encrypted message are wrapped into JSON: ```{
 40 |   "message": <encrypted message>,
 41 |   "nonce": <nonce>
 42 | }```, which is then saved into the KVS.
 43 | 
 44 | Any KVS value that is a valid JSON and has both `nonce` and `message` fields should be treated as encrypted according to the above algorithm.
 45 | 
 46 | ## Syntax
 47 | 
 48 | Transaction syntax is based on [AIP-10: General transaction structure for API calls](https://aips.adamant.im/AIPS/aip-10). KVS transaction type is 9.
 49 | 
 50 | Transaction `asset` object  must include single `state` object, which represents key-value pairs and store type:
 51 | 
 52 | ``` json
 53 | "asset": {
 54 |   "state": {
 55 |     "key": KEY_NAME,
 56 |     "value": VALUE,
 57 |     "type": KEY_TYPE
 58 |   }
 59 | }
 60 | ```
 61 | 
 62 | Contents explained:
 63 | 
 64 | - `key` describes contents of KVS record. Possible values must be described in future AIPs. String, mandatory.
 65 | - `value` is data for `key`. Mandatory, type depends on contents.
 66 | - `type` points how to process KVS records for this `key`. It may be incremental or full re-write of previous values. Must be described in future AIPs. Integer, mandatory. Default `0`.
 67 | 
 68 | ### Examples
 69 | 
 70 | ``` json
 71 | {
 72 |   "transaction": {
 73 |     "type": 9,
 74 |     "amount": 0,
 75 |     "senderId": "U11977883563659338220",
 76 |     "senderPublicKey": "d2cbc26c2ef6...",
 77 |     "asset": {
 78 |       "state": {
 79 |         "key": "eth:address",
 80 |         "value": "0xf4a2d5997eb0575b7ad7c10b0b178524c336f9e9",
 81 |         "type": 0
 82 |       }
 83 |     },
 84 |     "timestamp": 45603372,
 85 |     "signature": "86cbe525042bf83802..."
 86 |   }
 87 | }
 88 | 
 89 | ```
 90 | 
 91 | This transaction write *public* Ether address for U11977883563659338220.
 92 | 
 93 | ``` json
 94 | {
 95 |   "transaction": {
 96 |     "type": 9,
 97 |     "amount": 0,
 98 |     "senderId": "U15677078342684640219",
 99 |     "senderPublicKey": "e16e624fd0...",
100 |     "asset": {
101 |       "state": {
102 |         "key": "contact_list",
103 |         "value": "{
104 |           \"message\": \"6df8c172feef228d930130...\",
105 |           \"nonce\": \"f6c7b76d55db945bb026cd221d5...\"
106 |         }",
107 |         "type": 0
108 |       }
109 |     },
110 |     "timestamp": 45603645,
111 |     "signature": "dbafce549f1..."
112 |   }
113 | }
114 | ```
115 | 
116 | Sends *private* (encrypted) contact_list records for U15677078342684640219.
117 | 
118 | ## Rationale
119 | 
120 | Using two different systems for separate storage of public and sensitive data can be considered as not rationale. It should be clear that clients should distinguish between secret and public data, to know that data should be decoded. Public data could have some identifiers that are not efficient to store as JSON, because they are just plain strings or some data that can be written in string format. So ability to store strings and JSON objects should be considered as right way. Nodes shouldn't interfere with data stored in objects. So all data handling should be done on client.
121 | 
122 | Regarding encryption, most of KVS stored data is needed for use of one user, holder of the private/secret key of an account. So using NaCL public-key authenticated encryption (box) has no sense. To not introduce new encryption libraries, we can use Secret-key authenticated encryption (secretbox), using SHA-256 of private key as secret key.
123 | 
124 | ## Copyright
125 | 
126 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
127 | 


--------------------------------------------------------------------------------
/AIPS/aip-10.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 10
  3 | title: General transaction structure for API calls
  4 | author: Dmitriy Soloduhin (@zyuhel), Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/21
  6 | status: Accepted
  7 | type: Standards
  8 | category: API
  9 | created: 2019-02-12
 10 | ---
 11 | 
 12 | ## Simple Summary
 13 | 
 14 | Describing general structure of any ADAMANT transaction when communicating with API endpoints.
 15 | 
 16 | Further reading:
 17 | 
 18 | - [Node's API documentation](https://github.com/Adamant-im/adamant/wiki)
 19 | - [Swagger schema for ADAMANT node](https://github.com/Adamant-im/adamant-schema)
 20 | - [Try out ADAMANT API](https://schema.adamant.im)
 21 | 
 22 | ## Abstract
 23 | <!--A short (~200 word) description of the technical issue being addressed.-->
 24 | 
 25 | Transaction objects is the only way to write data into ADAMANT blockchain. This AIP aims to standartize transaction object structure. Any specific transaction type must follow this standard.
 26 | 
 27 | Transaction objects used when sending data to nodes' endpoints and also returned when querying ADAMANT nodes.
 28 | 
 29 | Since Node version [0.4.2](https://github.com/Adamant-im/adamant/releases/tag/v0.4.2) transactions can be sent to unified `/api/transaction` endpoint.
 30 | 
 31 | ## Specification
 32 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
 33 | 
 34 | ADAMANT transaction must comply with JSON scheme:
 35 | 
 36 | ```
 37 | {
 38 |   "id": TX_ID,
 39 |   "type": TX_TYPE,
 40 |   "amount": AMOUNT,
 41 |   "fee": AMOUNT,
 42 |   "senderId": ADAMANT_ID,
 43 |   "recipientId": ADAMANT_ID,
 44 |   "senderPublicKey": PUBLIC_KEY,
 45 |   "asset": JSON_OBJECT,
 46 |   "timestamp": ADAMANT_TIMESTAMP,
 47 |   "signature": SIGNATURE,
 48 |   "confirmations": UNSIGNED INTEGER,
 49 |   "height": UNSIGNED INTEGER,
 50 |   "blockId": BLOCK_ID
 51 | }
 52 | 
 53 | ```
 54 | 
 55 | Format types descriptions:
 56 | 
 57 | - `ADAMANT_ID` — ADAMANT address starting with `U`, string
 58 | - `ADAMANT_TIMESTAMP` — 32 bit integer epoch timestamp (in seconds starting from Sep 02 2017 17:00:00 GMT+0000)
 59 | - `AMOUNT` — tokens quantity in 64 bit integer, 8 decimal points (100000000 equals to 1 ADM)
 60 | - `PUBLIC_KEY` — 256 bit public key in hex, string
 61 | - `SIGNATURE` — ed25519 signature of SHA256 hash of transaction data in hex, string
 62 | - `TX_ID` — reversed first 8 bytes of SHA256 hash of transaction data and signature as integer
 63 | - `BLOCK_ID` — reversed first 8 bytes of SHA256 hash of signed block header
 64 | - `TX_TYPE` — integer representing [transaction type](#transaction-types)
 65 | 
 66 | Explanation of transaction fields:
 67 | 
 68 | - `type` — type of transaction. It says node how to interpret it, see below. Mandatory when posting a transaction to node.
 69 | - `amount` — amount to transfer. For non-transfer transactions must be `0`. Mandatory when posting a transaction to node.
 70 | - `fee` — fee for operation. Depends on `type` of transaction.
 71 | - `senderId` — ADAMANT address of sender. Mandatory when posting a transaction to node.
 72 | - `senderPublicKey` — public key of sender. Mandatory when posting a transaction to node.
 73 | - `recipientId` — ADAMANT address of recipient. Default is null. Mandatory for [chats and transfers (0,8)](#transaction-types).
 74 | - `asset` — transaction data specific for different [transaction types](#transaction-types). Used also in signature calculation. If omitted, it is set to empty object `{}`.
 75 | - `timestamp` — transaction timestamp. Nodes do not accept transactions stamped in future. Mandatory when posting a transaction to node.
 76 | - `signature` — transaction signature. Mandatory when posting a transaction to node.
 77 | - `confirmations` — number of confirmations. Must be omitted when posting a transaction to node.
 78 | - `height` — block height where transaction forged. Must be omitted when posting a transaction to node.
 79 | - `blockId` — block id where transaction forged. Must be omitted when posting a transaction to node.
 80 | 
 81 | ### Transaction types
 82 | 
 83 | Here are reserved types of transactions:
 84 | 
 85 | - `0` is for sending tokens
 86 | - `1` is for second signature
 87 | - `2` is for delegate registration
 88 | - `3` is for voting
 89 | - `4` is for multisignature
 90 | - `8` is for messaging (including Rich content) and In-Chat token transfers
 91 | - `9` is for storing data (KVS)
 92 | 
 93 | ### Examples
 94 | 
 95 | ``` json
 96 | {
 97 |   "transaction": {
 98 |     "type": 9,
 99 |     "amount": 0,
100 |     "senderId": "U11977883563659338220",
101 |     "senderPublicKey": "d2cbc26c2ef6...",
102 |     "asset": {
103 |       "state": {
104 |         "key": "eth:address",
105 |         "value": "0xf4a2d5997eb0575b7ad7c10b0b178524c336f9e9",
106 |         "type": 0
107 |       }
108 |     },
109 |     "timestamp": 45603372,
110 |     "signature": "86cbe525042bf83802..."
111 |   }
112 | }
113 | 
114 | ```
115 | 
116 | This transaction writes public Ether address for U11977883563659338220 in blockchain.
117 | 
118 | ``` json
119 | {
120 |   "id": "2119283124838898701",
121 |   "height": 1895256,
122 |   "blockId": "8715847094891653948",
123 |   "type": 0,
124 |   "timestamp": 16472909,
125 |   "senderPublicKey": "cdab95b082b9774bd975677c868261618c7ce7bea97d02e0...",
126 |   "senderId": "U15423595369615486571",
127 |   "recipientId": "U11962225491348738609",
128 |   "amount": 49000000,
129 |   "fee": 50000000,
130 |   "signature": "17132c3e62ce2671911e1ca...",
131 |   "signatures": [],
132 |   "confirmations": 5895508,
133 |   "asset": {}
134 | }
135 | ```
136 | 
137 | Transaction returned by ADAMANT node. Transfer of 0.49 ADM from U15423595369615486571 to U11962225491348738609.
138 | 
139 | ## Rationale
140 | 
141 | Describing current transaction structure will help to develop alternative ADAMANT clients and nodes.
142 | 
143 | ## Copyright
144 | 
145 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
146 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
  1 | CC0 1.0 Universal
  2 | 
  3 | Statement of Purpose
  4 | 
  5 | The laws of most jurisdictions throughout the world automatically confer
  6 | exclusive Copyright and Related Rights (defined below) upon the creator and
  7 | subsequent owner(s) (each and all, an "owner") of an original work of
  8 | authorship and/or a database (each, a "Work").
  9 | 
 10 | Certain owners wish to permanently relinquish those rights to a Work for the
 11 | purpose of contributing to a commons of creative, cultural and scientific
 12 | works ("Commons") that the public can reliably and without fear of later
 13 | claims of infringement build upon, modify, incorporate in other works, reuse
 14 | and redistribute as freely as possible in any form whatsoever and for any
 15 | purposes, including without limitation commercial purposes. These owners may
 16 | contribute to the Commons to promote the ideal of a free culture and the
 17 | further production of creative, cultural and scientific works, or to gain
 18 | reputation or greater distribution for their Work in part through the use and
 19 | efforts of others.
 20 | 
 21 | For these and/or other purposes and motivations, and without any expectation
 22 | of additional consideration or compensation, the person associating CC0 with a
 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
 25 | and publicly distribute the Work under its terms, with knowledge of his or her
 26 | Copyright and Related Rights in the Work and the meaning and intended legal
 27 | effect of CC0 on those rights.
 28 | 
 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be
 30 | protected by copyright and related or neighboring rights ("Copyright and
 31 | Related Rights"). Copyright and Related Rights include, but are not limited
 32 | to, the following:
 33 | 
 34 |   i. the right to reproduce, adapt, distribute, perform, display, communicate,
 35 |   and translate a Work;
 36 | 
 37 |   ii. moral rights retained by the original author(s) and/or performer(s);
 38 | 
 39 |   iii. publicity and privacy rights pertaining to a person's image or likeness
 40 |   depicted in a Work;
 41 | 
 42 |   iv. rights protecting against unfair competition in regards to a Work,
 43 |   subject to the limitations in paragraph 4(a), below;
 44 | 
 45 |   v. rights protecting the extraction, dissemination, use and reuse of data in
 46 |   a Work;
 47 | 
 48 |   vi. database rights (such as those arising under Directive 96/9/EC of the
 49 |   European Parliament and of the Council of 11 March 1996 on the legal
 50 |   protection of databases, and under any national implementation thereof,
 51 |   including any amended or successor version of such directive); and
 52 | 
 53 |   vii. other similar, equivalent or corresponding rights throughout the world
 54 |   based on applicable law or treaty, and any national implementations thereof.
 55 | 
 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of,
 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
 59 | and Related Rights and associated claims and causes of action, whether now
 60 | known or unknown (including existing as well as future claims and causes of
 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum
 62 | duration provided by applicable law or treaty (including future time
 63 | extensions), (iii) in any current or future medium and for any number of
 64 | copies, and (iv) for any purpose whatsoever, including without limitation
 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
 66 | the Waiver for the benefit of each member of the public at large and to the
 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver
 68 | shall not be subject to revocation, rescission, cancellation, termination, or
 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work
 70 | by the public as contemplated by Affirmer's express Statement of Purpose.
 71 | 
 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be
 73 | judged legally invalid or ineffective under applicable law, then the Waiver
 74 | shall be preserved to the maximum extent permitted taking into account
 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
 76 | is so judged Affirmer hereby grants to each affected person a royalty-free,
 77 | non transferable, non sublicensable, non exclusive, irrevocable and
 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in
 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration
 80 | provided by applicable law or treaty (including future time extensions), (iii)
 81 | in any current or future medium and for any number of copies, and (iv) for any
 82 | purpose whatsoever, including without limitation commercial, advertising or
 83 | promotional purposes (the "License"). The License shall be deemed effective as
 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the
 85 | License for any reason be judged legally invalid or ineffective under
 86 | applicable law, such partial invalidity or ineffectiveness shall not
 87 | invalidate the remainder of the License, and in such case Affirmer hereby
 88 | affirms that he or she will not (i) exercise any of his or her remaining
 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims
 90 | and causes of action with respect to the Work, in either case contrary to
 91 | Affirmer's express Statement of Purpose.
 92 | 
 93 | 4. Limitations and Disclaimers.
 94 | 
 95 |   a. No trademark or patent rights held by Affirmer are waived, abandoned,
 96 |   surrendered, licensed or otherwise affected by this document.
 97 | 
 98 |   b. Affirmer offers the Work as-is and makes no representations or warranties
 99 |   of any kind concerning the Work, express, implied, statutory or otherwise,
100 |   including without limitation warranties of title, merchantability, fitness
101 |   for a particular purpose, non infringement, or the absence of latent or
102 |   other defects, accuracy, or the present or absence of errors, whether or not
103 |   discoverable, all to the greatest extent permissible under applicable law.
104 | 
105 |   c. Affirmer disclaims responsibility for clearing rights of other persons
106 |   that may apply to the Work or any use thereof, including without limitation
107 |   any person's Copyright and Related Rights in the Work. Further, Affirmer
108 |   disclaims responsibility for obtaining any necessary consents, permissions
109 |   or other rights required for any use of the Work.
110 | 
111 |   d. Affirmer understands and acknowledges that Creative Commons is not a
112 |   party to this document and has no duty or obligation with respect to this
113 |   CC0 or use of the Work.
114 | 
115 | For more information, please see
116 | <http://creativecommons.org/publicdomain/zero/1.0/>
117 | 


--------------------------------------------------------------------------------
/AIPS/aip-14.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 14
  3 | title: Chatrooms API 
  4 | author: Dmitriy Soloduhin (@zyuhel), Sergey Ushakov (@sergushakov), Aleksei Lebedev (@adamant-al)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/14
  6 | status: Accepted
  7 | type: Standards
  8 | category: API
  9 | created: 2019-01-21
 10 | updated: 2021-11-24
 11 | ---
 12 | 
 13 | ## Simple Summary
 14 | <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the AIP.-->
 15 | To simplify access to chats and offer one common endpoint for chats and group chats in the future, current node's API need to be extended.
 16 | 
 17 | ## Abstract
 18 | <!--A short (~200 word) description of the technical issue being addressed.-->
 19 | Current API for retrieving chats are the same as for general transactions. It leads to ineffective work of messaging applications. To get full list of contacts, apps have to download all of transactions for a user. This behavior is very slow for users with multiple chats.
 20 | 
 21 | Effective solution is to create new chatroom endpoint that offers fetching contacts, chats and paginating through chatrooms.
 22 | 
 23 | ## Motivation
 24 | <!--The motivation is critical for AIPs that want to change the protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.-->
 25 | Chatrooms will make messenger apps faster and consume less memory.
 26 | 
 27 | ## Specification
 28 | <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.-->
 29 | New endpoint `/api/chatrooms` should be added to ADAMANT node. It uses REST notation.
 30 | 
 31 | Let user address is U000000000000 and he communicate with U000000000001. To get user's U000000000000 chats, GET request to `/api/chatrooms/U000000000000` should be sent. To get chat messages between U000000000000 and U000000000001, GET request to `/api/chatrooms/U000000000000/U000000000001` should be sent.
 32 | 
 33 | API endpoint for `/api/chatrooms/U000000000000` returns list of general `chats` structure:
 34 | 
 35 | ```
 36 | "chats": [{
 37 |   "lastTransaction": {
 38 |     "id": TX_ID,
 39 |     "type": TX_TYPE,
 40 |     "height": TX_HEIGHT,
 41 |     "timestamp": ADAMANT_TIMESTAMP,
 42 |     "senderPublicKey": PUBLIC_KEY,
 43 |     "senderId": ADAMANT_ID, 
 44 |     "recipientId": ADAMANT_ID,
 45 |     "recipientPublicKey": PUBLIC_KEY,
 46 |     "amount": AMOUNT,
 47 |     "fee": AMOUNT,
 48 |     "signatures": [array of SIGNATURE],
 49 |       "confirmations": UNSIGNED INTEGER,
 50 |     "asset": JSON_OBJECT,
 51 |   },
 52 |   "participants": [ 
 53 |     {
 54 |       "address": "ADAMANT_ID",
 55 |       "publicKey": "PUBLIC_KEY"
 56 |     }, {
 57 |       "address": "ADAMANT_ID",
 58 |       "publicKey": "PUBLIC_KEY"
 59 |     }, {...}
 60 |   ]
 61 | }, {...}
 62 | ]
 63 | ```
 64 | 
 65 | Format types and fields described in [AIP-10: General transaction structure for API calls](https://aips.adamant.im/AIPS/aip-10#specification). Array `participants` includes both sender's and recipient's addresses and public keys for chat dialog. Object `lastTransaction` contains information about last transaction with specific participant, including `asset` data.
 66 | 
 67 | List of all transactions in chat with specific recipient `/api/chatrooms/U000000000000/U000000000001` is returned in `messages` response field.
 68 | 
 69 | Along with `chats` array, endpoint returns `count` of chats or messages integer value. `count` is independent from `limit` argument, always returning total count.
 70 | 
 71 | Available arguments:
 72 | 
 73 | * `orderBy` — order by field, same as in [transaction list API](https://github.com/Adamant-im/adamant-console/wiki/Available-Commands#transactions), default is `timestamp:desc`
 74 | * `offset` — offset, same as in transaction list API, default is `0`
 75 | * `limit` — limit field, same as in transaction list API, default `25`
 76 | * `withoutDirectTransfers` — if direct ADM transfers ([transactions of type `0`](https://aips.adamant.im/AIPS/aip-10#transaction-types)) should not be returned, default `false`
 77 | 
 78 | ## Examples
 79 | 
 80 | Result of `api/chatrooms/U7972131227889954319` request:
 81 | 
 82 | ``` json
 83 | {
 84 |   "success": true,
 85 |   "nodeTimestamp": 46531132,
 86 |   "chats": [{
 87 |     "id": "7452709338464950789",
 88 |     "type": 8,
 89 |     "timestamp": 25726425,
 90 |     "senderPublicKey": "ce67b26e33391dd88ea2bc0173256b9c68a038888fc3de5b8b9887581ddd3239",
 91 |     "senderId": "U10879844458425463425",
 92 |     "recipientId": "U7972131227889954319",
 93 |     "recipientPublicKey": "d2885bc8d4aa68f0f4c919077c1edcb9c9020a715f20cb6db7578cd6f68055bb",
 94 |     "amount": 0,
 95 |     "fee": 100000,
 96 |     "signatures": [],
 97 |     "confirmations": null,
 98 |     "stored_value": null,
 99 |     "stored_key": null,
100 |     "asset": {
101 |       "chat": {
102 |         "message": "7b1e6e21f1f8e4be646133d5814b2ca5c60c0a9bac",
103 |         "own_message": "2a6b950be00ac83d289853251491486d0d403c81e5ce1213",
104 |         "type": 1
105 |       }
106 |     },
107 |     "participants": [{
108 |       "address": "U10879844458425463425",
109 |       "publicKey": "ce67b26e33391dd88ea2bc0173256b9c68a038888fc3de5b8b9887581ddd3239"
110 |     }, {
111 |       "address": "U7972131227889954319",
112 |       "publicKey": "d2885bc8d4aa68f0f4c919077c1edcb9c9020a715f20cb6db7578cd6f68055bb"
113 |     }]
114 |   }, {...}
115 |   ],
116 |   "count": "63"
117 | }
118 | ```
119 | 
120 | Result of `api/chatrooms/U7972131227889954319/U15677078342684640219` request:
121 | 
122 | ``` json
123 | {
124 |   "success": true,
125 |   "nodeTimestamp": 46534772,
126 |   "messages": [{
127 |     "id": "10194689778297980241",
128 |     "height": 840833,
129 |     "blockId": "18442279251222439707",
130 |     "type": 8,
131 |     "timestamp": 11049579,
132 |     "senderPublicKey": "d2885bc8d4aa68f0f4c919077c1edcb9c9020a715f20cb6db7578cd6f68055bb",
133 |     "requesterPublicKey": null,
134 |     "senderId": "U7972131227889954319",
135 |     "recipientId": "U15677078342684640219",
136 |     "recipientPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
137 |     "amount": 0,
138 |     "fee": 500000,
139 |     "signature": "0e5651909e77adb0bef384884e1f09c006b9403c1c9abeb36832df5c1fedeca6b5f2771bf84b273d27580e440acd823e6fbb3d2a55bf033512adc25711832501",
140 |     "signSignature": null,
141 |     "signatures": [],
142 |     "confirmations": null,
143 |     "stored_value": null,
144 |     "stored_key": null,
145 |     "asset": {
146 |       "chat": {
147 |         "message": "579636a8943c5f766e3bbbfaf75528d8a9e9b89878c0551c7f887f35c51034f32ba8bad35495e3f2c95af977c9b08d7b86c160c97456d1e426",
148 |         "own_message": "a13976c2635255df4d96ad412f60630478e146b9d6fe82db",
149 |         "type": 0
150 |       }
151 |     }
152 |   }, {...}
153 |   ],
154 |   "participants": [{
155 |     "address": "U7972131227889954319",
156 |     "publicKey": "d2885bc8d4aa68f0f4c919077c1edcb9c9020a715f20cb6db7578cd6f68055bb"
157 |   }, {
158 |     "address": "U15677078342684640219",
159 |     "publicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404"
160 |   }],
161 |   "count": "341"
162 | }  
163 | ```
164 | 
165 | ## Rationale
166 | <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
167 | Messenger clients need to get chats faster. As clients need to know public keys of all chats participants, it is rational to return them in requests.  Direct ADM token transfers may be hidden in some clients, so `withoutDirectTransfers` parameter added. `offset` and `limit` parameters allows to fetch data by parts and make client apps even faster.
168 | 
169 | ## Backwards Compatibility
170 | <!--All AIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The AIP must explain how the author proposes to deal with these incompatibilities. AIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
171 | This improvement adds new API endpoint, and won't change backward compatibility for any previous clients.
172 | 
173 | ## Copyright
174 | 
175 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
176 | 


--------------------------------------------------------------------------------
/AIPS/aip-18.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 18
  3 | title: Decentralized File Transfer
  4 | author: Aleksei Lebedev (@adamant-al), Stanislav Jelezoglo (@StanislavDevIOS)
  5 | discussions-to: https://github.com/Adamant-im/AIPs/issues/55
  6 | requires: 5
  7 | extends: https://aips.adamant.im/AIPS/aip-5
  8 | status: Accepted
  9 | type: Standards
 10 | category: ARC
 11 | created: 2024-03-21
 12 | ---
 13 | 
 14 | ## Simple Summary
 15 | 
 16 | This proposal introduces a decentralized file-transfer feature in ADAMANT Messenger apps.
 17 | 
 18 | ## Abstract
 19 | 
 20 | The ability to send files within a messaging platform enhances communication by providing users with a versatile and efficient means of sharing information. Sending files lets users exchange various types of content—documents, images, videos, and more—directly within the chat interface. This functionality promotes collaboration, facilitates the sharing of important documents, and enriches conversations by adding context and additional information.
 21 | 
 22 | The key distinction of file transfer in ADAMANT is its privacy-first approach, which relies on decentralized storage solutions such as the [InterPlanetary File System (IPFS)](https://en.wikipedia.org/wiki/InterPlanetary_File_System) and storage blockchains. This aligns with ADAMANT’s principles of privacy and censorship resistance.
 23 | 
 24 | ## Motivation
 25 | 
 26 | A comprehensive specification is necessary to establish a consistent and standardized approach to implementing decentralized file transfer in ADAMANT Messenger apps.
 27 | 
 28 | ## Specification
 29 | 
 30 | At a high level, decentralized file transfer consists of the following steps:
 31 | 
 32 | - Encrypting the file using the end-to-end encryption defined in [AIP-4](https://aips.adamant.im/AIPS/aip-4)
 33 | - Generating a file ID (locally on device)
 34 | - Uploading the encrypted file to a decentralized-storage node
 35 | - Sending that ID to the recipient in an ADM rich-text message
 36 | - Later, the recipient decrypts the ADM message, downloads the file (from any decentralized-storage node), and decrypts it.
 37 | 
 38 | While the encryption and decryption steps are covered in other AIPs, the process of embedding file IDs in messages requires its own specification.
 39 | 
 40 | Once a client has the file ID, it sends an ADM rich-text message, as described in [AIP-5](https://aips.adamant.im/AIPS/aip-5), containing both storage and file information. The `id` field represents the unique identifier of the file; other fields convey the file type, size, preview ID, file name, and nonces used for encryption.
 41 | 
 42 | ## Syntax
 43 | 
 44 | According to [AIP-5](https://aips.adamant.im/AIPS/aip-5), the field `transaction.asset.chat.message` must contain **encrypted, stringified** JSON that includes the attached-file information.
 45 | 
 46 | The structure of the file-transfer object is as follows:
 47 | 
 48 | ```json
 49 | {
 50 |   "files": [
 51 |     {
 52 |       "id": "String",
 53 |       "mimeType": "String",
 54 |       "extension": "String",
 55 |       "size": Int64,
 56 |       "preview": {
 57 |         "id": "String",
 58 |         "nonce": "String",
 59 |         "extension": "String"
 60 |       },
 61 |       "name": "String",
 62 |       "nonce": "String",
 63 |       "resolution": [Float, Float],
 64 |       "duration": Float
 65 |     }
 66 |   ],
 67 |   "storage": { "id": "String" },
 68 |   "comment": "String"
 69 | }
 70 | ```
 71 | 
 72 | Object fields:
 73 | 
 74 | - `files`: Array containing metadata for each attached encrypted file
 75 |   - `id`: Unique file identifier within `storage`
 76 |   - `mimeType`: MIME type of the file (optional)
 77 |   - `extension`: File-extension string (optional)
 78 |   - `size`: Size of the *encrypted* file in bytes
 79 |   - `preview`: Preview-image data (optional)
 80 |   - `name`: Original file name (optional)
 81 |   - `nonce`: Nonce used for encryption
 82 |   - `resolution`: [width, height] in pixels; useful for images and videos (optional)
 83 |   - `duration`: Duration of a video or audio file in seconds (optional)
 84 | - `storage`: Describes the decentralized storage in which the file resides
 85 | - `comment`: Caption or comment associated with the file (optional)
 86 | 
 87 | ### Examples
 88 | 
 89 | Object `transaction.asset.chat.message` *before encryption*, which includes a single file:
 90 | 
 91 | ``` json
 92 | {
 93 |   "storage": {
 94 |     "id": "ipfs"
 95 |   },
 96 |   "files": [
 97 |     {
 98 |       "id": "bafkreifxs2buan4anxwhfnt...v25rewteppsh6u4s4x5hi4o4du",
 99 |       "name": "IMG_308",
100 |       "resolution": [
101 |         1179,
102 |         2556
103 |       ],
104 |       "preview": {
105 |         "id": "bafkreidqpnqmqocqp...if4xb3bi76gl6g4kmtg62cmpw5ufu",
106 |         "nonce": "297d443aa29aa...485309f9f5ae159df9784d",
107 |         "extension": "jpeg"
108 |       },
109 |       "nonce": "030aa714943dc1dd...1c7091920d9d",
110 |       "mimeType": "image/jpeg",
111 |       "extension": "jpeg",
112 |       "size": 150998
113 |     }
114 |   ],
115 |   "comment": "Hello!"
116 | }
117 | ```
118 | 
119 | The entire transaction after encryption from U15677078342684640219 to U7972131227889954319 looks like this:
120 | 
121 | ``` json
122 | {
123 |   "transaction": {
124 |     "type": 8,
125 |     "amount": 0, // Amount should be 0
126 |     "senderId": "U15677078342684640219",
127 |     "senderPublicKey": "e16e624fd0a5123294b448c21f30a07a0435533c693b146b14e66830e4e20404",
128 |     "asset": {
129 |       "chat": {
130 |         "message": "70cbd07ff2ceaf0fc38a01ef9...", // encrypted files object
131 |         "own_message": "e98794eaedf47e...",
132 |         "type": 2 // Type should be 2 (Rich Content Message)
133 |       }
134 |     },
135 |     "recipientId": "U7972131227889954319",
136 |     "timestamp": 46116887,
137 |     "signature": "8fc2a54604109a6fcdccec2..."
138 |   }
139 | }
140 | ```
141 | 
142 | You can combine file sending with [AIP-16](https://aips.adamant.im/AIPS/aip-16) to reply to a message that has an attachment. Supply the following structure in the `reply_message` field:
143 | 
144 | ``` json
145 | {
146 |   "replyto_id": "7452709338464950789",
147 |   "reply_message": {
148 |     "storage": {
149 |       "id": "ipfs"
150 |     },
151 |     "files": [
152 |       {
153 |         "id": "bafkreifxs2buan4anxwhfnt...v25rewteppsh6u4s4x5hi4o4du",
154 |         "name": "IMG_308",
155 |         "resolution": [
156 |           1179,
157 |           2556
158 |         ],
159 |         "preview": {
160 |           "id": "bafkreidqpnqmqocqp...if4xb3bi76gl6g4kmtg62cmpw5ufu",
161 |           "nonce": "297d443aa29aa...485309f9f5ae159df9784d",
162 |           "extension": "jpeg"
163 |         },
164 |         "nonce": "030aa714943dc1dd...1c7091920d9d",
165 |         "mimeType": "video/quicktime",
166 |         "extension": "mov",
167 |         "size": 150998,
168 |         "duration": 129.3
169 |       }
170 |     ],
171 |     "comment": "Hello!"
172 |   }
173 | }
174 | ```
175 | 
176 | ## Transfer Scenario
177 | 
178 | ### Sender’s client
179 | 
180 | 1. Create a placeholder in the chat for the file transfer
181 | 2. Display the file(s) inside the placeholder with a spinner or progress indicator; the user can cancel the transfer at any time.
182 | 3. Encrypt the file(s)
183 | 4. Calculate the file ID(s) locally on device
184 | 5. Upload the encrypted file(s) to a storage node
185 | 6. Wait until the upload completes, retrieve the file ID(s), and verify that they match the locally calculated value(s). If a network issue occurs, let the user retry or cancel.
186 | 7. Send the ADM rich-text message. If a network issue occurs, let the user retry or cancel.
187 | 
188 | ### Recipient’s client
189 | 
190 | 1. Fetch and decrypt the ADM message
191 | 2. Create a placeholder for the file(s) in the chat with a spinner
192 | 3. *(Optional)* Fetch the preview image if *auto-preview* is enabled
193 | 4. *(Optional)* Fetch the full file if *auto-download* is enabled
194 | 5. Decrypt the file(s)
195 | 6. Replace the placeholder with the final content
196 | 
197 | As with in-chat crypto transfers, retry logic and timeouts depend on the message age; very recent transfers may need extra time before the file becomes available on the node to which the recipient is connected.
198 | 
199 | ## Assumptions and Limitations
200 | 
201 | Although ADAMANT’s privacy-first design is a core strength, it also introduces several limitations:
202 | 
203 | - Mandatory end-to-end encryption may introduce a slight UX delay and demands additional client-side resources
204 | - Forwarding attachments requires downloading the content and re-encrypting it with the new recipient’s public key
205 | - Decentralized storage networks can exhibit propagation delays between nodes
206 | - Most decentralized-storage solutions cannot guarantee file deletion; any node may retain a file indefinitely
207 | 
208 | ## Rationale
209 | 
210 | This AIP adds a file-sharing feature that follows the decentralized ethos of ADAMANT, providing strong privacy and censorship resistance. A standardized approach guarantees consistent behavior across all ADAMANT Messenger clients.
211 | 
212 | ## Copyright
213 | 
214 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
215 | 


--------------------------------------------------------------------------------
/AIPS/aip-1.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | aip: 1
  3 | title: AIP Purpose and Guidelines
  4 | status: Active
  5 | type: Meta
  6 | author: Dmitriy Soloduhin, Aleksei Lebedev <devs@adamant.im>
  7 | created: 2018-05-01
  8 | updated: 2021-11-02
  9 | ---
 10 | 
 11 | What is an AIP?
 12 | --------------
 13 | 
 14 | AIP stands for ADAMANT Improvement Proposal. An AIP is a document providing information to the community, or describing a new feature or its processes or environment. The AIP should provide a concise technical specification of the feature and a rationale for the feature. The AIP author is responsible for building consensus within the community and documenting dissenting opinions.
 15 | 
 16 | AIP Rationale
 17 | -------------
 18 | 
 19 | We intend AIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into live network. Because the AIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
 20 | 
 21 | Also AIPs help with bringing multiple implementation of ADAMANT Messengers to come to common standard with communication and storing data in blockchain.
 22 | 
 23 | For ADAMANT implementers, AIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the AIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
 24 | 
 25 | AIP Types
 26 | ---------
 27 | 
 28 | There are three types of AIP:
 29 | 
 30 | - A **Standard AIP** describes any change that affects most or all ADAMANT implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using ADAMANT. Furthermore Standard AIPs can be broken down into the following categories.
 31 |   - **Core**: improvements affecting node features.
 32 |   - **Networking**: includes improvements around network itself and cross-node communications.
 33 |   - **API**: includes improvements around client API/RPC specifications and standards, and also certain language-level standards.
 34 |   - **ARC**: (ADAMANT Request for Comments) application-level standards and conventions, including standards such URI schemes, library/package formats, naming restrictions and wallet formats.
 35 | - An **Informational AIP** describes an ADAMANT design issue, or provides general guidelines or information to the community, but does not propose a new feature. Informational AIPs do not necessarily represent  community consensus or a recommendation, so users and implementers are free to ignore Informational AIPs or follow their advice.
 36 | - A **Meta AIP** describes a process surrounding ADAMANT or proposes a change to (or an event in) a process. Meta AIPs focus mostly on social mechanisms and processes, not on technical implementation. Technical implementation for Meta AIPs can be made in Standard AIPs.
 37 | 
 38 | AIP Work Flow
 39 | -------------
 40 | 
 41 | The AIP repository editors change the AIPs status. Please send all AIP-related email to the AIP editors or preferably (e.g. for public transparency) you can ping one of the Editors that is involved with your pull request (PR); they are listed under [AIP editors below](#Aip-editors). Also see [AIP Editor Responsibilities & Workflow](#aip-editor-responsibilities-and-workflow).
 42 | 
 43 | The AIP process begins with a new idea for ADAMANT. It is highly recommended that a single AIP contain a single key proposal or new idea. A change to one client doesn't require an AIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does. The AIP editor reserves the right to reject AIP proposals if they appear too unfocused or too broad. If in doubt, split your AIP into several well-focused ones.
 44 | 
 45 | Each AIP must have a champion—someone who writes the AIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.
 46 | 
 47 | Vetting an idea publicly before going as far as writing an AIP is meant to save the potential author time. Asking the community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where ADAMANT is used. Examples of appropriate public forums to gauge interest around your AIP include  [the Issues section of this repository]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your AIP.
 48 | 
 49 | Once the champion has asked the ADAMANT community whether an idea has any chance of acceptance a draft AIP should be presented as a [pull request].
 50 | 
 51 | If the AIP editors approve the AIP ([see the AIP editors workflow section below for details](#eip-editor-responsibilities-and-workflow)) and the authors are happy for it to be merged as a draft, the AIP editor will assign the AIP a number and merge your pull request. The AIP editor will not unreasonably deny an AIP. (AIP authors can request for it to be merged after they have finished editing it, and editors can ask if they have finished editing it and would like it to be merged. This prevents merging an AIP when more edits are intended to be made by the author, although it can always be edited after merging.) Reasons for denying AIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the ADAMANT philosophy.
 52 | 
 53 | Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the AIP to be mature and ready to proceed to the next phase.
 54 | 
 55 | Standards AIPs consist of two parts, a design document and implementation. The AIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the AIP. Standards Core AIPs must be implemented in live network before it can be considered Final.
 56 | 
 57 | For an AIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
 58 | 
 59 | Once an AIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to “Final”.
 60 | 
 61 | An AIP can also be assigned status “Deferred”. The AIP author or editor can assign the AIP this status when no progress is being made on the AIP. Once an AIP is deferred, the AIP editor can re-assign it to draft status.
 62 | 
 63 | An AIP can also be “Rejected”. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
 64 | 
 65 | AIPs can also be superseded by a different AIP, rendering the original obsolete.
 66 | 
 67 | The possible paths of the status of AIPs are as follows:
 68 | 
 69 | ![AIP Process](../assets/aip-1/aip_process.png)
 70 | 
 71 | Some Informational and Process AIPs may also have a status of “Active” if they are never meant to be completed, e.g. AIP 1 (this AIP).
 72 | 
 73 | What belongs in a successful AIP?
 74 | ---------------------------------
 75 | 
 76 | Each AIP should have the following parts:
 77 | 
 78 | - Preamble—RFC 822 style headers containing metadata about the AIP, including the AIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. See [below](#Aip-header-preamble) for details.
 79 | <!-- -->
 80 | 
 81 | - Simple Summary—“If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the AIP.
 82 | 
 83 | <!-- -->
 84 | 
 85 | - Abstract—a short (~200 word) description of the technical issue being addressed.
 86 | 
 87 | <!-- -->
 88 | 
 89 | - Motivation (*optional)—The motivation is critical for AIPs that want to change the ADAMANT protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright.
 90 | 
 91 | <!-- -->
 92 | 
 93 | - Specification—The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for different platforms.
 94 | 
 95 | <!-- -->
 96 | 
 97 | - Rationale—The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
 98 | 
 99 | <!-- -->
100 | 
101 | - Backwards Compatibility—All AIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The AIP must explain how the author proposes to deal with these incompatibilities. AIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
102 | 
103 | <!-- -->
104 | 
105 | - Test Cases—Test cases for an implementation are mandatory for AIPs that are affecting consensus changes. Other AIPs can choose to include links to test cases if applicable.
106 | 
107 | <!-- -->
108 | 
109 | - Implementations—The implementations must be completed before any AIP is given status “Final”, but it need not be completed before the AIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.
110 | 
111 | <!-- -->
112 | 
113 | - Copyright Waiver—All AIPs must be in the public domain. See the bottom of this AIP for an example copyright waiver.
114 | 
115 | AIP Formats and Templates
116 | -------------------------
117 | 
118 | AIPs should be written in [markdown] format.
119 | Image files should be included in a subdirectory of the `assets` folder for that AIP as follow: `assets/Aip-X` (for AIP **X**). When linking to an image in the AIP, use relative links such as `../assets/aip-X/image.png`.
120 | 
121 | AIP Header Preamble
122 | -------------------
123 | 
124 | Each AIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens ('---'). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
125 | 
126 | ` aip ` : < AIP number > (this is determined by the AIP editor)
127 | 
128 | ` title ` : < AIP title >
129 | 
130 | ` author ` : < a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below. >
131 | 
132 | ` discussions-to `* : < url >
133 | 
134 | ` status ` : < Draft / Active / Accepted / Deferred / Rejected / Withdrawn / Final / Replaced >
135 | 
136 | ` type ` : < Standard (Core, Networking, Interface, API, ARC) / Informational / Meta >
137 | 
138 | ` category `* : < Core / Networking / Interface / API / ARC >
139 | 
140 | ` created ` : < date created on, in ISO 8601 (yyyy-mm-dd) format >
141 | 
142 | ` updated ` : < date updated on, in ISO 8601 (yyyy-mm-dd) format >
143 | 
144 | ` requires `* : < AIP number(s) >
145 | 
146 | ` replaces `* : < AIP number(s) >
147 | 
148 | ` replaced-by `* : < AIP number(s) >
149 | 
150 | ` resolution `* : < url >
151 | 
152 | #### Author header
153 | 
154 | The author header optionally lists the names, email addresses or usernames of the authors/owners of the AIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:
155 | 
156 | Random J. User &lt;address@doma.in&gt;
157 | 
158 | or
159 | 
160 | Random J. User (@username)
161 | 
162 | if the email address or GitHub username is included, and
163 | 
164 | Random J. User
165 | 
166 | if the email address is not given.
167 | 
168 | Note: The resolution header is required for Standard AIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the AIP is made.
169 | 
170 | While an AIP is a draft, a discussions-to header will indicate the mailing list or URL where the AIP is being discussed. As mentioned above, examples for places to discuss your AIP include  an issue in this repo or in a fork of this repo. No discussions-to header is necessary if the AIP is being discussed privately with the author.
171 | 
172 | The type header specifies the type of AIP: Standard, Meta, or Informational. If the track is Standard please include the subcategory (core, networking, interface, API, or ARC).
173 | 
174 | The category header specifies the AIP's category. This is required for standard AIPs only.
175 | 
176 | The created header records the date that the AIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
177 | 
178 | AIPs may have a requires header, indicating the AIP numbers that this AIP depends on.
179 | 
180 | AIPs may also have a replaced-by header indicating that an AIP has been rendered obsolete by a later document; the value is the number of the AIP that replaces the current document. The newer AIP must have a Replaces header containing the number of the AIP that it rendered obsolete.
181 | 
182 | Headers that permit lists must separate elements with commas.
183 | 
184 | Auxiliary Files
185 | ---------------
186 | 
187 | AIPs may include auxiliary files such as diagrams. Such files must be named AIP-XXXX-Y.ext, where “XXXX” is the AIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”).
188 | 
189 | AIP Editors
190 | -----------
191 | 
192 | The current AIP editors are
193 | 
194 | `* Dmitriy Soloduhin (@zyuhel)`
195 | 
196 | `* Alexey Lebedev (@adamant-al)`
197 | 
198 | `* Alexander Kiselev (@MaaKut)`
199 | 
200 | AIP Editor Responsibilities and Workflow
201 | --------------------------------------
202 | 
203 | For each new AIP that comes in, an editor does the following:
204 | 
205 | - Read the AIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
206 | - The title should accurately describe the content.
207 | - Check the AIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style
208 | 
209 | If the AIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
210 | 
211 | Once the AIP is ready for the repository, the AIP editor will:
212 | 
213 | - Assign an AIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this AIP)
214 | 
215 | <!-- -->
216 | 
217 | - Accept the corresponding pull request
218 | 
219 | <!-- -->
220 | 
221 | - Send a message back to the AIP author with the next step.
222 | 
223 | Many AIPs are written and maintained by developers with write access to the Ethereum codebase. The AIP editors monitor AIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
224 | 
225 | The editors don't pass judgment on AIPs. We merely do the administrative & editorial part.
226 | 
227 | History
228 | -------
229 | 
230 | This document was derived heavily from [Ethereum's EIP-1] written by Martin Becze and Hudson Jameson, which in turn was derived from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. So all writers of original text are not responsible for its use in the ADAMANT Improvement Process, and should not be bothered with technical questions specific to ADAMANT or the AIP. Please direct all comments to the AIP editors.
231 | 
232 | See [the revision history for further details](https://github.com/Adamant-im/AIPs/commits/master/AIPS/aip-1.md), which is also available by clicking on the History button in the top right of the AIP.
233 | 
234 | Bibliography
235 | ------------
236 | 
237 | - [pull request](https://github.com/Adamant-im/AIPs/pulls)
238 | - [the Issues section of this repository](https://github.com/Adamant-im/AIPs/issues)
239 | - [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet)
240 | - [Ethereum's EIP-1](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md)
241 | - [Bitcoin's BIP-0001](https://github.com/bitcoin/bips)
242 | - [Python's PEP-0001](https://www.python.org/dev/peps/)
243 | 
244 | Copyright
245 | ---------
246 | 
247 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
248 | 


--------------------------------------------------------------------------------