gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The messenger service is ready to use


From: TheJackiMonster
Subject: Re: The messenger service is ready to use
Date: Sat, 06 Mar 2021 18:55:21 +0100
User-agent: Evolution 3.38.4

On Sat, 2021-03-06 at 17:42 +0100, carlo von lynX wrote:
> On Sat, Mar 06, 2021 at 04:09:17PM +0100, TheJackiMonster wrote:
> > I'm not currently sure if we should use JSON (which is more common
> > in
> > current web) or use PSYC (which would be more efficient). The
> > service
> > itself should allow both, so this would probably be something to
> > decide
> > on application level.
> 
> Being common is not of particular use actually. The ability to
> properly maintain semantics is relevant and another aspect came
> to my mind: the way you can throw any binary blob into it without
> further processing -- so having a meme gif or a profile jpeg
> doesn't require any conversion or reference to out-of-band
> storage.

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.

So file formats and similar are not really an issue which needs to
addressed via a text based format for messages.

> 
> > About secushare: I am probably going to look into the protocol of
> > secushare again before implementing the client-side library, so
> > there
> > won't be too many problems making both compatible in the future.
> > However I can't tell currently if the protocols work together or
> > the
> > traffic can be handled. I still need stress-tests. ^^'
> 
> The relevant concepts here are how everything is a pubsub channel,
> profiles are aggregations of pubsubs and any pubsub can scale
> up to endless amount of users by multicast distribution (unlike
> those dirty hack pubsubs like PubSubHubbub or IPFS pubsub).

I will definitely look more into it.

> 
> > Also it may be possible to get the client-side library compatible
> > with
> > Telegram for example but I would first look into getting
> > applications
> > done with less features. If we have proper interfaces we can think
> > about compatibility. ^^'
> 
> I was thinking of leveraging the fact that people *also* need
> Telegram and would possibly appreciate a Telegram client which
> *additionally* supports GNUnet for actual private chat.
> 
> Considering also that Telegram will start putting advertisements
> into large channels… so people will have an interest in
> migration but remain backward compatible. Therefore having
> yet another messenger isn't as interesting as offering a
> full service slide from current to next generation messaging.

Yes, this makes sense. The problems I see with compatibility to
Telegram are that Telegram is very different in its concepts.

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

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

There are many more differences which will probably be more clear when
I've provided the documentation. For now I can just say, it is not as
simple to provide compatibility to any existing messenger than creating
a fully functional interface for the service. Some features from
messengers like Telegram are still missing (or have to be automated),
some others which are implemented do not exist in these existing
messengers.

I would assume currently that compatibility will most likely be
possible through a Matrix bridge but I wouldn't exclude direct
compatibility to other messengers yet.

> 
> 
> 

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]