1 files changed, 0 insertions, 27 deletions
diff --git a/docs/IDEAS.txt b/docs/IDEAS.txt
deleted file mode 100644
index d1be2ce6..00000000
--- a/docs/IDEAS.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-A couple of ideas posted in the threads.
-#############
-    Prescence (online/offline)
-     - A user's id being present with a valid signature in the DHT implies they have been online recently. A ping to the user would confirm this, as well as notifying them that you are online. If both friends in a pair actively search for the other then disruption due to lag in inserting records will be mimimised
-     
-    Username (nick) changes
-     - When a user wants to change their nick they are free to do so, the nick is not cryptographically significant. The nick change could be shared in-band with the chat (ie, each message in the format "username - message") or out of band, perhaps in the dht values or in the ping messgaes.
-     
-    File send
-     - I see a file being sent as ultimately the same as an audio stream or a video stream being sent, they could use the same protocol parts. The client would handle what to do with the data whether it is a stream of media data or a stream of b64'd file. both would require explicit verification from the other participant. This would also allow sharing of streamed files, eg incomplete downloads.
-##############
- ability to log in with username and password
-    possible implementation: store keys in a server and use user/pass to retrieve keys from server transparently
-   >too centralized
- looking up people and adding as contacts, etc by name or username
-    possible implementation: store pubkey-hash/info correspondences in a public directory, integrate access into client
- portable contact list/profile/other account data
-    just store it along with keys in aforementioned server; cost of storage could rise... potential problem
- POSSIBLY interfacing with regular phones. probably not possible, but plebs might complain (THIS IS EXPENSIVE (hence 'probably not possible')) <3
-IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso
-    > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten the normalfags, since it's not shown by default). Also, 2 UIs would be chaos to maintain.
-##############

diff --git a/docs/IDEAS.txt b/docs/IDEAS.txt deleted file mode 100644 index d1be2ce6..00000000 --- a/docs/IDEAS.txt +++ /dev/null
@@ -1,27 +0,0 @@
1	A couple of ideas posted in the threads.
2
3	#############
4	Prescence (online/offline)
5	- A user's id being present with a valid signature in the DHT implies they have been online recently. A ping to the user would confirm this, as well as notifying them that you are online. If both friends in a pair actively search for the other then disruption due to lag in inserting records will be mimimised
6
7	Username (nick) changes
8	- When a user wants to change their nick they are free to do so, the nick is not cryptographically significant. The nick change could be shared in-band with the chat (ie, each message in the format "username - message") or out of band, perhaps in the dht values or in the ping messgaes.
9
10	File send
11	- I see a file being sent as ultimately the same as an audio stream or a video stream being sent, they could use the same protocol parts. The client would handle what to do with the data whether it is a stream of media data or a stream of b64'd file. both would require explicit verification from the other participant. This would also allow sharing of streamed files, eg incomplete downloads.
12
13	##############
14
15	- ability to log in with username and password
16	possible implementation: store keys in a server and use user/pass to retrieve keys from server transparently
17	>too centralized
18	- looking up people and adding as contacts, etc by name or username
19	possible implementation: store pubkey-hash/info correspondences in a public directory, integrate access into client
20	- portable contact list/profile/other account data
21	just store it along with keys in aforementioned server; cost of storage could rise... potential problem
22	- POSSIBLY interfacing with regular phones. probably not possible, but plebs might complain (THIS IS EXPENSIVE (hence 'probably not possible')) <3
23
24	IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso
25	> I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten the normalfags, since it's not shown by default). Also, 2 UIs would be chaos to maintain.
26	##############
27