Re: The messenger service is ready to use

[carlo von lynX]

Good morning!

> > 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.

On Sat, Mar 06, 2021 at 09:47:48PM +0100, TheJackiMonster wrote:
> The question is what kind of files to people actually share through
> messengers. Uncompressed pictures, videos or other media should be

They throw gifs, songs, video clips at each other just to
express a +1 or a lol.

> 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.

That means that *all* messages need to be binary data messages so
that you can include gifs, jpegs, m4as, mp4s.. because pretty much
any kind of message sent to the group could be illustrated with any
of those things. If you start making exceptions people will start
complaining why they can't put a gif into the group description
or decorate a "/me is cleaning the house" message with an upload
of queen's "i want to break free". So my recommendation here is
to not raise artificial barriers and to not require every anigif
to be stored in gnunet-fs. We can still find the optimal balance
between immediacy and cachability later.

> > > 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).

Those are techniques introduced to complement the architecture
of the web, but we do not depend on that. The web artificially
creates a realtimeness stress for users to interact with servers,
but we can just display the complete message when it has fully
arrived. No need to start showing previews and fill the user's
screen with unfinished things.

Should you consider going forther someday, think how websites in
secushare are static views of the channel state of subscribed
channels, thus when a person clicks on a menu item, it typically 
refers to something which is already in the local memory. No
latency, no tricks needed, no possibility to measure click patterns
for purposes of surveillance capitalism. Oh, one more reason to
use PSYC: the channel state it manages. It's a bit like git, PSYC
as a series of messages executes modifications on a set of data
elements, therefore as an application you can always look at the
state for the current view of a chatroom's or a person's profile etc.

> > > 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. ^^'

We can make registration with regular Telegram optional
for those who need it. I'm still talking about the advantage
of using a powerful existing UI with generally accepted UX.
Maybe the code already sports some levels of negotation, so
if the server doesn't offer certain things, those options
will not show up in the UI. In our case the server is a
localhost gnunet service.

> > 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.

As a general principle I don't believe in opt-in. I think it is the
reason why GDPR is mostly a failure - assuming people have the ability
to judge what long term implications it will have to give consent to
data slavery. I was told there are psychological studies detailing
how the human species is unable to make such decisions reasonably,
they cannot even visualize the long term effects of smoking.

So in the long run I would love people to use physical meetings
(bluetooth, NFC, QR-code handshakes etc) combined with adoption
from other people's social graph. But as long as it isn't illegal
to use more invasive instruments, by not employing them we're just
giving the unregulated offerings a strategic advantage. Even Telegram
was created after Snowden's revelations with the intention of being a
privacy-oriented alternative, but in order to compete with Whatsapp
they had to put all the privacy second or third and make things as
easy and comfortable for users as their spoiled expectation is.
It's ugly, but it's the reason why they are still in the game.

> 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.

Well, if you don't know by which method a person put herself into
the DHT or GNS, then you end up inserting as much data as you have -
so the data exposure is not happening through the person herself but
through her contacts. Ironically, this behaviour is actually illegal
by data protection regulation: you would have to ask for permission
before you use *any* data of another person. And so the commercial
social networks strive on the fact that, legally speaking, it's your
own friends committing the crime, not the social network provider.
Have you ever considered sueing a friend because they posted your
photo on Facebook?

Therefore I expect it will be both much more comfortable and much
safer if there are options for discovery within the social graph,
so if I am Robert's good friend, I can add his friend Michelle that
I met at his party last night, by searching his branch of the graph.

Also, I'm not sure how well the use of DHT and GNS is protected
from systematic attacks. Can I, by knowing someone's email address,
publish a wrong pubkey in her name? Can I DoS a person out of existence?
The social graph doesn't have these problems.. luckily GNS mostly
promotes social graph style modeling, but not enough to build secushare
upon, AFAIR. In particular the frequent traversal that an app like
secushare needs would be a stress on the DHT rather than on a locally
managed database.

> > > 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.
> 
> 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

Same with secushare. Every conversation is a group, not a 1:1.

> 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. ^^'
> 
> 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.

That has the disadvantage that a client which is honest to their
users could indicate to their users that there is some "whispering"
going on in the chatroom. In secushare we've been hoping/planning/
postulating that channel creation must be rather cheap, therefore
for any new subgroup of recipients you would create a dedicated
multicast group, irrespective of whether that subgroup happens to
be in one or several chatrooms together, and/or just happen to
share a certain view of somebody's social profile as that person
has categorized them as friends of a special kind. Say you have 50
people that were at your wedding - they have access to your wedding
videos on your secushare profile and sit in two chatrooms related
to the event - distributionwise it all goes through the same multicast
as long as the recipient group is identical.

Should that assumption prove wrong, then we need approximizations
such as "whispering" over existing channels, sending irrelevant
data and notifications to smartphones that can't even decipher them.


-- 
  E-mail is public! Talk to me in private using encryption:
   //  http://loupsycedyglgamf.onion/LynX/
  //    irc://loupsycedyglgamf.onion:67/lynX
 //    https://psyced.org/LynX/