diff options
author | irungentoo <irungentoo@gmail.com> | 2015-01-03 22:27:00 -0500 |
---|---|---|
committer | irungentoo <irungentoo@gmail.com> | 2015-01-03 22:27:00 -0500 |
commit | b68d7f0245a09be188eff63afa4a3041733b2238 (patch) | |
tree | cc01fb21e8edfe91bcecfdf39264fd068afe379b | |
parent | d4ea2809dbe7ef52ea44129750ba12438aa4d046 (diff) | |
parent | 840d182de2ba7401a78d86e423e7ef12d41d7688 (diff) |
Merge branch 'fix-typos' of https://github.com/aaannndddyyy/toxcore
-rw-r--r-- | docs/Avatars.md | 66 |
1 files changed, 34 insertions, 32 deletions
diff --git a/docs/Avatars.md b/docs/Avatars.md index 6be4b471..1dcbba96 100644 --- a/docs/Avatars.md +++ b/docs/Avatars.md | |||
@@ -5,18 +5,18 @@ | |||
5 | ## Introduction and rationale | 5 | ## Introduction and rationale |
6 | 6 | ||
7 | User avatars are small icons or images used to identify users in the friend | 7 | User avatars are small icons or images used to identify users in the friend |
8 | list; they exists in virtually all VoIP and IM protocols and provide an easy | 8 | list; they exist in virtually all VoIP and IM protocols and provide an easy |
9 | way to an user identify another in the friend list. | 9 | way for one user to identify another in the friend list. |
10 | 10 | ||
11 | This document describes the implementation of avatars in the Tox protocol, | 11 | This document describes the implementation of avatars in the Tox protocol, |
12 | according to the following design considerations: | 12 | according to the following design considerations: |
13 | 13 | ||
14 | - Avatars are handled as private information, ie., only exchanged over | 14 | - Avatars are handled as private information, i.e., they are only exchanged over |
15 | Tox encrypted channels among previously authenticated friends; | 15 | Tox encrypted channels among previously authenticated friends; |
16 | 16 | ||
17 | - The library treats all images as blobs and does not interpret or | 17 | - The library treats all images as blobs and does not interpret or |
18 | understands image formats, only ensures that the avatar data sent by | 18 | understand image formats. It only ensures that the avatar data sent by |
19 | an user is correctly received by the other. The client application is | 19 | a user is correctly received by the other. The client application is |
20 | responsible for validating, decoding, resizing, and presenting the | 20 | responsible for validating, decoding, resizing, and presenting the |
21 | image to the user. | 21 | image to the user. |
22 | 22 | ||
@@ -28,17 +28,17 @@ according to the following design considerations: | |||
28 | 28 | ||
29 | **Notice:** As designed, this limit can be changed in the future without | 29 | **Notice:** As designed, this limit can be changed in the future without |
30 | breaking the protocol compatibility, but clients using the original | 30 | breaking the protocol compatibility, but clients using the original |
31 | limit will reject larger avatars; | 31 | limit will reject larger avatars. |
32 | 32 | ||
33 | - The protocol MUST provide means to allow caching and avoid unnecessary | 33 | - The protocol MUST provide means to allow caching and avoid unnecessary |
34 | data transfers; | 34 | data transfers. |
35 | 35 | ||
36 | - Avatars are transfered between clients in a background operation; | 36 | - Avatars are transfered between clients in a background operation. |
37 | 37 | ||
38 | - Avatars are served in a "best effort" basis, without breaking clients | 38 | - Avatars are served on a "best effort" basis, without breaking clients |
39 | who do not support them; | 39 | which do not support them. |
40 | 40 | ||
41 | - The protocol MUST resist to malicious users; | 41 | - The protocol MUST resist to malicious users. |
42 | 42 | ||
43 | - The protocol MUST work with both UDP and TCP networks. | 43 | - The protocol MUST work with both UDP and TCP networks. |
44 | 44 | ||
@@ -50,20 +50,20 @@ it silently. This procedure can be improved to provide the previously stated | |||
50 | design considerations, but this requires a higher integration with the core | 50 | design considerations, but this requires a higher integration with the core |
51 | protocol. Moving this feature to the core protocol also: | 51 | protocol. Moving this feature to the core protocol also: |
52 | 52 | ||
53 | - Provides a simpler and cleaner interfaces for client applications; | 53 | - provides a simpler and cleaner interface for client applications; |
54 | 54 | ||
55 | - Hides protocol complexities from the client; | 55 | - hides protocol complexities from the client; |
56 | 56 | ||
57 | - Avoids code duplication and ad-hoc protocols in the clients; | 57 | - avoids code duplication and ad-hoc protocols in the clients; |
58 | 58 | ||
59 | - Avoids incompatibility between client implementations; | 59 | - avoids incompatibility between client implementations; |
60 | 60 | ||
61 | - Allows important optimizations such as lightweight notification of | 61 | - allows important optimizations, such as lightweight notification of |
62 | removed and updated avatars; | 62 | removed and updated avatars; |
63 | 63 | ||
64 | - Plays well with cache schemes; | 64 | - plays well with cache schemes; |
65 | 65 | ||
66 | - Makes avatar transfer an essentially background operation. | 66 | - makes avatar transfer essentially a background operation. |
67 | 67 | ||
68 | 68 | ||
69 | 69 | ||
@@ -72,35 +72,37 @@ protocol. Moving this feature to the core protocol also: | |||
72 | 72 | ||
73 | ## High level description | 73 | ## High level description |
74 | 74 | ||
75 | |||
76 | This is a very high level description. The usage patterns expected from | ||
77 | client applications are described in the section "Using Avatars in Client | ||
78 | Applications", and a low level protocol description is available in the | ||
79 | section "Internal Protocol Description".) | ||
75 | The avatar exchange is implemented with the following new elements in the | 80 | The avatar exchange is implemented with the following new elements in the |
76 | Tox protocol. This is a very high level description and the usage patterns | 81 | Tox protocol: |
77 | expected from client applications are described in Section "Using Avatars | ||
78 | in Client Applications" and a low level protocol description is available | ||
79 | in Section "Internal Protocol Description". | ||
80 | 82 | ||
81 | - **Avatar Information Notifications** are events which may be sent by | 83 | - **Avatar Information Notifications** are events which may be sent by |
82 | an user to another anytime, but are usually sent after one of them | 84 | a user to another anytime, but are usually sent after one of them |
83 | connects to the network, changes his avatar, or in reply to an **avatar | 85 | connects to the network, changes his avatar, or in reply to an **avatar |
84 | information request**. They are delivered by a very lightweight message | 86 | information request**. They are delivered by a very lightweight message |
85 | but with information enough to allow an user to validate or discard an | 87 | but with information enough to allow a user to validate or discard an |
86 | avatar from the local cache and decide if is interesting to request the | 88 | avatar from the local cache and to decide if it is interesting to request the |
87 | avatar data from the peer. | 89 | avatar data from the peer. |
88 | 90 | ||
89 | This event contain two data fields: (1) the image format and (2) the | 91 | This event contains two data fields: (1) the image format, and (2) the |
90 | cryptographic hash of the actual image data. Image format may be NONE | 92 | cryptographic hash of the actual image data. The image format may be NONE |
91 | (for users who have no avatar or removed their avatars) or PNG. The | 93 | (for users who have no avatar or removed their avatars) or PNG. The |
92 | cryptographic hash is intended to be compared with the hash of the | 94 | cryptographic hash is intended to be compared with the hash of the |
93 | currently cached avatar (if any) and check if it stills up to date. | 95 | currently cached avatar (if any) in order to check if it is still up to date. |
94 | 96 | ||
95 | - **Avatar Information Requests** are very lightweight messages sent by an | 97 | - **Avatar Information Requests** are very lightweight messages sent by a |
96 | user asking for an **avatar information notification**. They may be sent | 98 | user asking for an **avatar information notification**. They may be sent |
97 | as part of the login process or when the client thinks the currently | 99 | as part of the login process or when the client thinks the currently |
98 | cached avatar is outdated. The receiver may or may not answer to this | 100 | cached avatar is outdated. The receiver may or may not answer to this |
99 | request. This message contains no data fields; | 101 | request. This message contains no data fields. |
100 | 102 | ||
101 | - An **Avatar Data Request** is sent by an user asking another for his | 103 | - An **Avatar Data Request** is sent by a user asking another for his |
102 | complete avatar data. It is sent only when the requesting user decides | 104 | complete avatar data. It is sent only when the requesting user decides |
103 | the avatar do not exists in the local cache or is outdated. The receiver | 105 | the avatar does not exist in the local cache or is outdated. The receiver |
104 | may or may not answer to this request. This message contains no data | 106 | may or may not answer to this request. This message contains no data |
105 | fields. | 107 | fields. |
106 | 108 | ||