Hello,
@LeoNeeson! Thanks for your interest and time for test this.
- (Bug) if we insert ":" in a message, then any text/word after that is not shown.
This because ":" symbol is the delimiter, you can see this in source code and inside the file content.
As you can see in the source code, delimiter is ": " (":+white_space"), so links with https:// is working, for example.
File with message contains next data: "USERNAME,delimiter,message".
This delimiter can be any symbol, or even dynamic delimiter, as the hash from message, for example.
We can using special unicode characters, like
Zero-width space or another symbol, which will be trimmed or cann't be writed.
Just rewrite this strings in chat.js:
//message received.
83: var nickname = this.responseText.split(': ')[0]; //insert nickname
84: var message = this.responseText.split(': ')[1]; //insert message
...
131: name+ ': ';
But I fixed this bug, using this code:
//message received.
var nickname = this.responseText.split(': ', 1)[0]; //insert nickname
var message = this.responseText.split(nickname+': ', 2)[1]; //insert message
Also, I see another bug - many sounds elements with id="chatAudio" in the source code in html-page in browser.
This was been fixed by code in last message.If delimiter will be changed, I see another problem. Anyone can uploading any message with custom delimiter,
then not all messages will be available for each user.
Incrementing message nubmer is automatically for each uploading.
As you can see in the source code, each message saved by POST query, as file with one name "message.txt".
- Automatically scroll-down messages, so we can always see the last posted message.
You can scroll fasly if you press SHIFT button, and click in the end of scroll bar.
But you are right, it can be automatically.
This is client-side software, and you can do with this source code anything, what do you want.
Just using css-code "overflow: scroll" for div element, and Javascript or jquery scrolling functions.
And... I want to say next for you...
When many messages there is exists in textarea, scrolling functions can lagging...
I tested this JQuery method:
$('#chat-area').animate({ scrollTop: window_height + chat_height }, 'slow', function (){});
So better way to already see last message, will be next...
Just invert message filling in textarea!function get_file(number){...
xhr.onload = function(){
...
//replase this
//var code = '<p>'+'<span>'+nickname+'</span>'+message+'</p>'; //add tags to message
//document.getElementById('chat-area').innerHTML += code; //display this
//to this ->
var code = '<p>'+'<span>'+nickname+'</span>'+message+'</p>'; //add tags to message
document.getElementById('chat-area').innerHTML = code + document.getElementById('chat-area').innerHTML; //display this in top
}
}
Now, last message you can always see in the top of textarea, without any scrolling.
As you can see all textarea data will be copying every time when this will be filled.
So you can limit this in this step, for example to see last 100, 1000 messages only and not more than.
For example, in last message, I did set limit as 1000 messages, using split html content by '</p>' delimiter with 100 messages limit.
I did test '<p>' and '</p>' tags inside the messages, and I see all tags is closed autumatically in my browser, without any bugs.
- Show the number of users online, or even better, have a simple online user list.
There is no any signalling about the status "online".
Maybe, to do this, need to create a separate file, and rewrite this when user authorized,
and correct this, if user is not active within some time limit (not wrote any message).
But any rewrition of file will opening the backdoor to do damage this file from anyone.
I think will be better to using another server-side script, implemented to HFS.
- Save/remember nickname on a cookie, and allow change nickname when clicking on it.
Is HFS working with cookies? I see only 1 cookie file with HFS_SID in my browser settings.
If cookies can be sent, then you can rewrite the souce code and don't ask username in prompt, if cookie is exists.
I wrote this chat as simple and portable IRC-althernative, to working in TOR.
I have .onion domain and this is better than any DDNS. And as I remember, Tor Browser have strength cookies-policy.
- Add an optional 'Send' button (as a fail-over, for old browsers not detecting when the 'Enter' key is pressed).
This is HTML/JS - coding. You can add this yourself using standard form methods. And post the source code in this thread, then.
In this case javascript functions can be called by methods form onsubmit="function_name()", and onclick="function_name()"
By default, message will be sent after press "enter", according JQuery code
//textarea functions...
in the file chat.js
I don't know what browsers cann't using JQuery, but this can be excluded too.
- Privacy: If possible, save messages using the epoch Unix Time,
to avoid someone automatically stealing all the messages,
since it's currently searching for "message (2).txt", "message (3).txt", etc.
Nice idea. Seems like private rooms.
But as I said I created this as analogue of public IRC-channel in Local Network.
In IRC you can see private rooms too, but this is a channel, and this need Internet connection.
For example, you can connect here:
https://webchat.freenode.net/ to #tox channel with any username,
and do chating online with Tox developers community.
In LAN IRC - not working... And this HFS-chat working in LAN.
If number in filename will be changed, then any random user cann't do loading this simply.
I saw the problem in this, earler, but now...
How I see private rooms implementation?
1. Alice and Bob, select the key and do key exchange using DH.
2. Both calculating hash(from this key).
3. Rewtire "message"
prefix (not number) as "hash(from_key)" and save the messages, encrypted by this key.
(For example, can be using AES algoritm to do encryption/decryption message content, and save this as HEX.)
4.
- No any user must not and cann't download this messages.
- Admin cann't read this messages (he don't know key for encryption/decryption.)
- Admin can delete this messages, as admin for files in folder.
- Bob and Alice can download messages, by simply
incremention suffix (number about which you say).
- Add a private chat mode: when a private chat with some user is started, a new window is opened, and a new -temporal- folder is created on HFS, with a random folder name (for example "TempChat-5560AFHG") so, another users can't guess the folder path and steal or retrieve private chats.
Hehheh... This folder must be uploadable, and only HFS-admin can switch this.
To using security, as I said, Alice and Bob can using encryption/decryption in public chat.
No any user cann't read message without decryption key in this case,
but so many messages can be available in public to download...
If folder not recursively hidden, then any user can see file prefix,
and then save the same files with spam random values,
and in this case, Alice and Bob cann't decrypt this, but will got spam-loading.
So the private rooms, as I said Alice and Bob can using hash of key as prefix for filename with messages.
And in this case loading to server will be lower than in the case with just encrypted messages in public room.
And when one of the users close your browser, the private chat ends, and the another user gets a message like 'John has closed this chat' (similar as IRC).
Hm... This seems like WebRTC. Peer2Peer connection with random identifier for each private chat-room.
To make p2p connections, need the stun-server, or another relay-server - must be implemented in server-side software for make peers exchange.
To see any status value, need to do signalling between users.
All signals will be go to the server in this case, and as you can see this is HFS server, then signals will be saved AS FILES.
AS MANY-MANY FILES (without deletion, of course)...
So will be better to do peer exchange, and directly data exchange between the peers.
Then will be possible to do video-chat, or voice chat, like VOIP, with lowest server loading.
And then, we can also automatically delete that temporal folder, when both parts close the window.
You cann't delete the folder, because in this case, this deletion can do anyone then.
But admin can do special permissions for you, as for authorized user.
In this case you must to contact to admin, and do logining to HFS server.
We can also create a -permanent- private chat (with a folder name like "PermChat-EASY777"), adding a button to make it, so if 2 users know the 'private chat name' (aka: private chat folder name), for example "EASY777", then, they can join the chat anytime without having to post anything on the public chat (that folder stores the messages permanently).
Hm... In this case, you need to be authorized on admin's HFS-server, or download HFS yourself, create folder with your own name,
and rewrite the pathways in HFS_JQuery_chat. Folder must be uploadable.
You can hide this folder! And you can do this - recursivelly hidden! To hide files inside this folder from anyone. Yeap...
But not from sniffers, because XHR using DNS. In TOR this can be secure, because TOR use encryption.
So basically, we can have a public chat, and a private chat and all without a database or anything special.
As I wrote in the top, this is possible in 1 uploadable folder, if:
1. Messages will be encrypted. (Can be used assymetric cryptography!)
2. Prefix for files will be changed in the source code.
3. Auto-increment for files containing the encrypted messages with this prefix.
And more no need nothing. To use assymetric cryptography can be used JS library, like js-nacl,
RSA, Diffie-Hellman key exchange, etc... You can find this here + BigInteger:
https://github.com/username1565You can also check the chat made by DJ, here (which can give you some new fresh ideas).
Thanks for your link. I did test this, but private messages in last version not working.
There is "..." for receiver. Template not working for me, in HFS 2.2.
https://rawr.thatstevensguy.com/
I did download
Thunderchicken of Glory v4.0.3 and test this.
I see "mini chat" with id="Shoutbox" and the folder "template\shoutbox"
I see there is each message in each file too.
There is IP of user and timestamp in filename, and HTML content inside the file.
This chat is not secure if IP leak to admin, because any admin can be not good, IMHO.
Best regards, and have a nice day.