A new look for Matokai and more security
Hello. It’s time for another Matokai development update. I’ve been a few hours late on writing this post because I’ve been occupied with fixing a bug I’ll explain in a bit.
This week is quite exciting as I’ve made quite some progress. So, without any delay - let’s get started.
Let’s face it, the old logo looks like it was made in Microsoft Paint in ten minutes (albeit false). The font reminded multiple people of Comic Sans.
I decided it was time for a make-over. Say hello to the new Matokai logo!
I believe this logo looks far better than the old one, and I’m happy with how it turned out.
Changing your username
People grow out of their old online aliases all the time, so it was trivial for Matokai to offer a feature where users can change their usernames.
This feature has now been implemented!
Its usage is quite straight forward. You just enter a new name (you’ll immediately know if it’s taken or not) and enter your password and click the button. It’s really simple.
The only limitation I’ve added is that you can only change your username so many times per hour to avoid confusion and abuse.
Changing your email address
It’s common for people to change their email addresses. Maybe they’re switching from Outlook to Gmail. Matokai aims to grow with you and so, I have implemented a feature to allow users to change their email address.
Just like changing your username, you’ll immediately see if your new email address is valid and available. To avoid typos, I have added an extra dialog asking you to check double-check your input.
After changing your email address, you are required to verify it again.
The internet is a fun place. It’s also a wild place. Matokai will require users to verify their email address before they can fully start using the application. For example, you can’t add friends until your email address is verified.
Needless to say, Matokai needed email verification. That is now a reality:
I do not believe I have to elaborate much more than this. It’s a good feature to have.
Design change #1 - Calls
I decided it would look good if the background during calls had more color. Instead of having one solid color.
It would look really great to have a blurred version of your profile picture as your call background.
I believe this looks good and makes the application feel more polished. Of course, I’ll be improving this even more in the future.
Design change #2 - Profile picture uploaded successfully!
As a direct result of the call design, I wanted a similar effect when you uploaded your profile picture, so it stands out more.
This looks a lot nicer than before. (It used to just be a dark background with no color - like other dialogs). Best part? If you upload a GIF - your background also moves with it. How cool is that?
The issue that delayed this post a little
When taking the screenshots you just saw, I noticed Firefox was having a problem connecting when calling. It turns out my previous check to identify whether you’re on Firefox had been “fixed” because Firefox 113 now offers
RTCPeerConnection.connectionState. Fixing that wasn’t the big problem though.
While fixing that, I decided I wanted to do a small test run - call clients from outside the loopback interface. I started to run into a small problem:
Peers are not aware of their own IP address. I had tried to fix that by manually modifying the SDP offer along with its re-negotiations. While that had worked for Chrome, it didn’t work for Firefox because the ICE candidates are formatted differently.
To avoid having to maintain multiple, I ended up adding Google’s STUN servers. It’s probably a temporary thing, as I don’t like being dependent on other providers too much but for now, I believe it’s a fine solution. I’ll have to host my own STUN server later.
It doesn’t stop there. Firefox also has a weird connectivity issue where audio tracks are simply not sent after all ICE candidates are “retrieved” - in quotes. Why? Firefox seems to think it has retrieved them all while in reality, it will attempt to do it again after the RTCPeerConnection instance has connected to the RTC server. This effectively means that either:
- You had to wait 10 seconds before audioTracks would be transmitted
- You had to wait for someone to join your call (ICE re-renegotiation)
- Worst case would be… it just never working.
Obviously, this wasn’t good. In Chrome, it worked just fine. I ended up adding the media streams before connecting, forcing Firefox to actually collect all ICE candidates before connecting. That had solved the problem!
People say Firefox is good. Oh-well.
That’s it for now!
As always, I thank you for following the development of Matokai. I unfortunately couldn’t implement 2FA in time for this post so that’ll be delayed for next week.
I can’t wait to update you all again next week.