Re: The messenger service is ready to use

[TheJackiMonster]

On Sat, 2021-03-06 at 21:15 +0100, carlo von lynX wrote:
> On Sat, Mar 06, 2021 at 06:55:21PM +0100, TheJackiMonster wrote:
> > Files will most likely be shared through the FS submodule of
> > GNUnet.
> > They get encrypted and the key for decryption gets shared through
> > the
> > messenger service. That's quite similar to the implementation of
> > Threema except this is fully decentralized.
> 
> Super inefficient for small pieces of data I would assume,
> and introducing so much latency that in the end it feels
> slower than using the web. When simple things arrive in-band
> you can display them immediately. I'd rather use FS for
> things >1M.

The question is what kind of files to people actually share through
messengers. Uncompressed pictures, videos or other media should be
fine. If we want to have low latency, I would suggest to add a message
type for binary data streaming directly since voice messages or video
streams are also common messenger features which would have the same
issue.

> 
> > So file formats and similar are not really an issue which needs to
> > addressed via a text based format for messages.
> 
> It's one of the few things that is *still* annoying with
> modern messengers such as Telegram: you get to see a
> blurred preview that was somehow embedded into JSON
> and then depending on the condition of your network
> you may have to wait seconds or minutes until the
> actual content materialises on the screen. That's what
> you get when you introduce OOB-fetching transactions
> just because your message format can't handle data
> natively.

If we really want to have lowest latency as possible for pictures and
previews, I know some formats we could look into (for example streaming
pixels in a LOD like way increasing pixel density by every level of
transmission).

> 
> > Yes, this makes sense. The problems I see with compatibility to
> > Telegram are that Telegram is very different in its concepts.
> 
> True, so it would need some mapping and cheating…
> 
> > For example Telegram requires personal information to create an
> > account. The messenger service doesn't require anything (no name,
> > no
> > mail address, no phone number) except that you have direct or
> > indirect
> > access to a peer running GNUnet. ^^'
> 
> Which brings about the disadvantage of having to "add" each
> person interactively before being able to even start. Would
> be ok if there was no unfair competition, but messengers
> are unfair competition.

The current state is far from being able to convince anyone switching
from one existing messenger to this. But I can definitely say that you
won't have to physically exchange peer identities or similar to add a
contact. I can only provide cadet-gtk as example which allows every
user to opt-in to share their peer-identity linked to personal
information.

So when I say "the service doesn't require anything", I don't mean you
can't use them. I just want to have a maximum of privacy by ensuring
every piece of personal data is optional. So in the end it depends on
each user if you can add them by a random number, a QR code, a tag-
name, a username or their email address.

The practical problem with compatibility is just that you will have
more options with the planned client-side library in adding contacts
practically than with any existing messenger I know.

> 
> > Also you can't mix end-to-end encrypted messages with transport-
> > only-
> > encrypted messages in Telegram (or at least the interface would
> > require
> > major changes to handle that).
> 
> But in our case it would simply be an extra E2E on top of
> CADET's Axolotl… pretty unnecessary.

Yes, the E2E is on top of CADET which seems to be unnecessary but it is
also optional. The most communication will only use CADETs encryption
if the user does not explicitly request otherwise.

However the E2E ensures that you can privately send a message to only
one or multiple selected members of a chatroom. So you are able to
invite them to private chatrooms which can be opened dynamically or to
just send other sensible information which is not intended for everyone
in the chatroom.

The whole design is based on the concept that a direct chat between two
people is basically just a group of two. So all chats (huge or small
groups) get treated as the same. The user can still decide to use E2E
for every message they send which is as inefficient as Signal, Threema
and multiple other messengers out there. ^^'

> 
>

signature.asc
Description: This is a digitally signed message part