Initial commit
This commit is contained in:
commit
e52e465d6a
7 changed files with 208 additions and 0 deletions
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
|
@ -0,0 +1 @@
|
|||
public/
|
3
.gitmodules
vendored
Normal file
3
.gitmodules
vendored
Normal file
|
@ -0,0 +1,3 @@
|
|||
[submodule "themes/kiss"]
|
||||
path = themes/kiss
|
||||
url = https://github.com/ribice/kiss.git
|
11
Makefile
Normal file
11
Makefile
Normal file
|
@ -0,0 +1,11 @@
|
|||
#
|
||||
# Makefile
|
||||
# Maxime "Pepe_" Buquet, 2018-02-21 00:12
|
||||
#
|
||||
|
||||
all:
|
||||
rm -rf public
|
||||
hugo --baseURL "https://test.bouah.net" --buildDrafts --debug
|
||||
|
||||
# vim:ft=make
|
||||
#
|
6
archetypes/default.md
Normal file
6
archetypes/default.md
Normal file
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "{{ replace .Name "-" " " | title }}"
|
||||
date: {{ .Date }}
|
||||
draft: true
|
||||
---
|
||||
|
16
config.toml
Normal file
16
config.toml
Normal file
|
@ -0,0 +1,16 @@
|
|||
BaseURL = "https://blog.bouah.net"
|
||||
languageCode = "en-us"
|
||||
title = "Grumpy pep."
|
||||
author = "pep."
|
||||
theme = "kiss"
|
||||
copyright = "© <a href=\"https://bouah.net\">Maxime “pep” Buquet</a> 2018. Licensed under <a href=\"https://creativecommons.org/licenses/by-sa/4.0/\">CC-BY-SA 4.0</a> unless specified."
|
||||
googleAnalytics = ""
|
||||
enableRobotsTXT = true
|
||||
disqusShortname = ""
|
||||
|
||||
[params.info]
|
||||
homeTitle = "Sysadmin Apprentice"
|
||||
poweredby = true
|
||||
|
||||
[params.social]
|
||||
email = "blog@bouah.net"
|
170
content/post/best-im.md
Normal file
170
content/post/best-im.md
Normal file
|
@ -0,0 +1,170 @@
|
|||
---
|
||||
title: "Best IM of the world"
|
||||
date: 2015-06-13T12:00:00+09:00
|
||||
tags: [IM, XMPP]
|
||||
---
|
||||
|
||||
__This is a translation of [this article in French](https://nl.movim.eu/?blog/edhelas@movim.eu/urn:md5:f34f066261bc7ea4ff7840470c1b5b4d).__
|
||||
|
||||
|
||||
Although Instant Messaging (also known as IM) has been in our everyday life
|
||||
for a while now, I am under the impression that we limit ourselves to old
|
||||
habits or features that we could update to offer our users innovative and
|
||||
modern services they all dream about.
|
||||
|
||||
Here I will share some groundbreaking ideas of mine that flourished as I have
|
||||
worked for a few years in this field. You are free to do whatever you want
|
||||
with them. Maybe they could be a base for some next generation application
|
||||
and revolutionize our communication process.
|
||||
|
||||
Fasten your seatbelt and let's go!
|
||||
|
||||
## 1. Redesign Authentication!
|
||||
|
||||
Let's be honest, credentials are crap, registering an account is counterintuitive
|
||||
and annoying. The first thing I would suggest is to rethink the whole
|
||||
registration process. This little form you know, that every user must fill in
|
||||
on each service, website or platform he wants to log in for the first time.
|
||||
|
||||
To tell the truth, when the user face this registration form, he hesitates,
|
||||
it's always a burden to have to fill in these fields. Why not just remove this
|
||||
step? The first time a user logs in, we attribute him a unique identifier (a
|
||||
number). We would then invite him to fill in his profile, since he would
|
||||
already be logged he would much easily give in information needed to complete
|
||||
this step.
|
||||
|
||||
The point is to manage to correctly uniquely identify the user before getting
|
||||
any input. Impossible? It depends what your target platform is. Say we want to
|
||||
build an IM service for mobile phone, we can use the [IMEI][1], or just the
|
||||
phone number currently in use. Smart isn't it?
|
||||
|
||||
[1]: https://en.wikipedia.org/wiki/International_Mobile_Station_Equipment_Identity
|
||||
|
||||
## 2. Federate the network?
|
||||
|
||||
The previous idea comes with some limitation. Since we want to make the
|
||||
registration process execute automatically, we can't ask the user where he
|
||||
wants to register his account. We don't want to make the user choose, that will
|
||||
lead him to hesitate, and would increase the chances that he would leave.
|
||||
|
||||
The best solution is certainly to skip this step as well. We would have a
|
||||
unique server where every account is created. This way we would have one user,
|
||||
one cell phone, one unique account, one service.
|
||||
|
||||
Better, don't you think?
|
||||
|
||||
## 3. Add new contacts
|
||||
|
||||
Once again, users are lazy, and once the account is created they always have
|
||||
to add in or invite people they want to talk to. This long and tedious process
|
||||
can discourage even the most brave. It would be nice to already have a contact
|
||||
list ready for use, with whom the user could talk right away.
|
||||
|
||||
Where can we find such a list? There must be something on the phone that we
|
||||
can use, like a phonebook. Bingo! Let's take the whole list of contacts, send
|
||||
it to our server, match it to phone numbers that are already registered and link the
|
||||
accounts. This supports our idea of the phone number being the unique
|
||||
identifier.
|
||||
|
||||
Nobody will have any problems with the fact that we keep their phonebook on our
|
||||
server in exchange for the great service we provide, right?
|
||||
|
||||
## 4. Respect the users
|
||||
|
||||
The previous idea is quite appealing, but it can scare users who are concerned about
|
||||
their privacy, and their contacts that wouldn't like their numbers to be sent to a server that they
|
||||
don't know about. What can we do to reassure them about handling their personal data?
|
||||
|
||||
There is one word that can calm everyone down: encryption. If
|
||||
communications are encrypted it shows that we do care about their privacy,
|
||||
right? We can guarantee them that communications between our users and the
|
||||
server will be encrypted. A bit of SSL/TLS here and there and we're done!
|
||||
|
||||
We can go a step further in this direction to prove our good faith and show
|
||||
that we want a modern and innovative service, and encrypt every single
|
||||
message! It doesn't really matter since we already have:
|
||||
|
||||
- the user's phone number,
|
||||
- his profile,
|
||||
- his complete phonebook with all the attached data (email, address, etc.),
|
||||
- and also the entirety of his exchanges (sender, receiver, sending time,
|
||||
receiving time, reading time, answering time, weight of the content, etc.).
|
||||
|
||||
And as we know, [metadata is by far more important than the data][2] so
|
||||
end-to-end encryption is a good compensation for all this generosity.
|
||||
|
||||
[2]: http://www.souverainetenumerique.fr/projet-de-loi-sur-le-renseignement-quelles-perspectives-pour-la-confiance-et-la-s%C3%A9curit%C3%A9-sur
|
||||
|
||||
## 5. Bonus idea: Open the platform
|
||||
|
||||
In order for us to maintain the users' trust, we can play the openness card, believe me it works
|
||||
every single time. We need two killer arguments for this:
|
||||
|
||||
#### Provide an API
|
||||
|
||||
Of course! Some reworking of the communication protocol, a bit of
|
||||
documentation in our Wiki and here it is! Openness. Users can now talk to the
|
||||
world and write libraries in any language they want. Don't forget to have some
|
||||
authorization protocol so you can strike off those who would try to look too
|
||||
close.
|
||||
|
||||
#### Open our client applications
|
||||
|
||||
Open sourcing our clients would definitely guarantee transparency. Just do it.
|
||||
We can then prove that encryption is applied correctly without any flaw. We
|
||||
can keep a few backdoors in apps we compile and distribute while keeping the
|
||||
codebase opened.
|
||||
|
||||
A nice ripple effect that we will gain from opening the codebase is
|
||||
contributions, bugfixes and new features from the community. We keep a hand on
|
||||
the API so we can monitor what comes in and goes out. Be careful of [not being
|
||||
too chatty][3], though.
|
||||
|
||||
[3]: http://www.theguardian.com/technology/2015/may/28/marauders-map-chrome-app-tracks-facebook-messenger
|
||||
|
||||
## That's it!
|
||||
|
||||
Here are some ideas that will definitely help you in building the new IM
|
||||
application on mobile, you can even try porting it to other platforms with a
|
||||
few changes.
|
||||
|
||||
With the third idea, I can guarantee you exponential growth since you get an
|
||||
entire phonebook each time a new user subscribes.
|
||||
|
||||
Playing the card of openness can be done later, in case problems concerning
|
||||
privacy surface, so you can claim transparency. It will
|
||||
depend on how open you want to be concerning your users' privacy.
|
||||
|
||||
## Nobody told me?
|
||||
|
||||
It seems there are already such apps:
|
||||
|
||||
- [WhatsApp](https://www.whatsapp.com/)
|
||||
- [Telegram](https://telegram.org/) (They played both bonus points from the
|
||||
start and they are pretty clear on [how they get their contacts][4], in the
|
||||
FAQ:
|
||||
|
||||
> Q: Who can I write to?
|
||||
>
|
||||
> You can write to people, who are in your phone contacts and have Telegram.
|
||||
|
||||
- [Line](http://line.me/en/)
|
||||
- [Viber](http://www.viber.com/en/)
|
||||
- [WeChat](http://www.wechat.com/en/)
|
||||
- [KakaoTalk](http://www.kakao.com/)
|
||||
- etc.
|
||||
|
||||
[4]: https://telegram.org/faq#q-who-can-i-write-to
|
||||
|
||||
For more ideas:
|
||||
|
||||
- [Facebook Messenger](https://play.google.com/store/apps/details?id=com.facebook.orca&hl=en)
|
||||
- [Google Hangouts](http://www.google.fr/hangouts/)
|
||||
|
||||
And for those who are not lazy, there is real Instant Messaging, there is
|
||||
[XMPP](https://xmpp.org).
|
||||
|
||||
|
||||
__This article is also available [via XMPP](xmpp:ppjet@bouah.net?;node=urn:xmpp:microblog:0;item=22c35ed3c91fe721f83574df9a1a59bb).__
|
||||
|
||||
*Thanks to liori and lool0 for the help and corrections.*
|
1
themes/kiss
Submodule
1
themes/kiss
Submodule
|
@ -0,0 +1 @@
|
|||
Subproject commit b533b89149abf5f3255c0ec53a1e1171e281c470
|
Loading…
Reference in a new issue