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/
