Document not found (404)
+This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +On base of password will be generted keypair for signing and keypair for encoding.
+ {
+ request_type: "registration",
+ username: "user",
+ password: "passwd123",
+ }
+ {
+ request_type: login,
+ username: "name",
+ decode_key: "key",
+ sign_key: "key",
+ }
+Each user have :w
+ +(pseudocode in Bash style)
+Hole receiving messages by looking for new items in "user's bin" (place where new messages arrives). Because of how freenet works, we can't just say "Hey! Do I have new messages?", we can specify messages index like: "Hey! Gimme 15th message". Thus we must remember previous message index and to receive the new message we're requesting for 16th message, if we was able to get 15th message.
+That's mean, what interlocutor also have to know the last message index in our bin. But how he can know it, if there's a lot of other users who also sending messages to our bin? Of course, you can try to receive all messages from the index, you had last remembered, and next index, next, next... until you find the index which does not exist. But it's a freenet, it's take too much time;
+The solution is unique Id. User creating and giving his/her unique id to each new interlocutor. And when, if interlocutor sending the message he knows, that last message to us had index $N and sends message with index $N+1, if be more verbose, the new message index he send to us will look like "$(ID)_($N+1)"
Each user have kind of a bin among freenet network,in which anyone can put message. And for each user this bin is his USK insert key. Each message signed by sender. And user can answer to sender, buy putting message at sender insert key if he know it.
Each user have unique pseudonym for each user whom he communicates. Thos pseudonyms uses by user to identify who is sender end establish message flow. +The "message flow" is important here.
+To receive a new message we have to send ClientGet to our USK request key with URI like /user_id-message_version. As well, the identifier is consists of user_id-message_number
+For example:
ClientGet
+URI=USK@myMessageBinKey/messages/user5678-3
+Identifier=request-user5678-3
+Verbosity=0
+ReturnType=direct
+EndMessage
+To send a message to a friend we putting it at his USK insert key, with URI like/my_id-$(number_of_messages_to_this_user + 1). And identifier like user_id-$(number_of_messages_to_this_user + 1)
+For example:
ClientGet
+URI=USK@myFriendBinKey/messages/user3246-5
+Identifier=user3501-5
+Verbosity=0
+ReturnType=direct
+EndMessage
+Hole generates file, which alice have to send to bob somehow, and bob have to do the same. This file will contain unique ID and two keys
+ +(pseudocode in Bash style)
+Hole receiving messages by looking for new items in "user's bin" (place where new messages arrives). Because of how freenet works, we can't just say "Hey! Do I have new messages?", we can specify messages index like: "Hey! Gimme 15th message". Thus we must remember previous message index and to receive the new message we're requesting for 16th message, if we was able to get 15th message.
+That's mean, what interlocutor also have to know the last message index in our bin. But how he can know it, if there's a lot of other users who also sending messages to our bin? Of course, you can try to receive all messages from the index, you had last remembered, and next index, next, next... until you find the index which does not exist. But it's a freenet, it's take too much time;
+The solution is unique Id. User creating and giving his/her unique id to each new interlocutor. And when, if interlocutor sending the message he knows, that last message to us had index $N and sends message with index $N+1, if be more verbose, the new message index he send to us will look like "$(ID)_($N+1)"
Each user have kind of a bin among freenet network,in which anyone can put message. And for each user this bin is his USK insert key. Each message signed by sender. And user can answer to sender, buy putting message at sender insert key if he know it.
Each user have unique pseudonym for each user whom he communicates. Thos pseudonyms uses by user to identify who is sender end establish message flow. +The "message flow" is important here.
+To receive a new message we have to send ClientGet to our USK request key with URI like /user_id-message_version. As well, the identifier is consists of user_id-message_number
+For example:
ClientGet
+URI=USK@myMessageBinKey/messages/user5678-3
+Identifier=request-user5678-3
+Verbosity=0
+ReturnType=direct
+EndMessage
+To send a message to a friend we putting it at his USK insert key, with URI like/my_id-$(number_of_messages_to_this_user + 1). And identifier like user_id-$(number_of_messages_to_this_user + 1)
+For example:
ClientGet
+URI=USK@myFriendBinKey/messages/user3246-5
+Identifier=user3501-5
+Verbosity=0
+ReturnType=direct
+EndMessage
+Hole generates file, which alice have to send to bob somehow, and bob have to do the same. This file will contain unique ID and two keys
+On base of password will be generted keypair for signing and keypair for encoding.
+ {
+ request_type: "registration",
+ username: "user",
+ password: "passwd123",
+ }
+ {
+ request_type: login,
+ username: "name",
+ decode_key: "key",
+ sign_key: "key",
+ }
+Each user have :w
+ +