gnunet-developers
[Top][All Lists]
Advanced

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

Re: Looking to contribute to GNUnet


From: address@hidden
Subject: Re: Looking to contribute to GNUnet
Date: Sat, 9 Mar 2024 10:30:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0


On 3/7/24 21:09, carlo von lynX wrote:
On Thu, Mar 07, 2024 at 12:49:07PM +0530, valdaarhun wrote:
Or how's the idea of writing a new communicator plugin for
TNG? For eg., a plugin for XMPP [4]? I am not sure if this needed
in GNUnet. I thought I would put my idea out there to get some
feedback.
I tried to pretend not having seen this but it didn't work.

I'll skip my criticism about XMPP[1] and mention something
so fundamental that it makes a lot of existing protocols
not very useful via GNUnet: In GNUnet people can connect
and communicate directly with each other, so the whole
architecture of servers and federation no longer makes
a lot of sense.

XMPP can work fine through p2p. Its just not being done a lot because of other reasons i can expand if needed.

Side note: I am creating an application that is distributed based on Spritely with ocaps and GNS and gnunet thats how i know :)


Also I doubt the general public would be interested in a
messenger that can't deliver voice, video and stickers
embedded into the protocol natively without overhead.

What do you mean "overhead" or "natively" here? Because every single protocol out there works with extensions. In the sense of virtually all protocols nowadays use webrtc which is not native to anything (except web i guess but what is web :P )

and second can you give an example of stickers integrated natively into the protocol? Because I can't imagine why stickers would be a protocol level thing since they are just pictures. Its al UI. The only thing a protocol has to dictate is how to share packs which xmpp already does.


IMHO it makes more sense to adapt the open source Telegram[2]
implementations to connect to a localhost server which then
offers backend functionality for Telegram to run over GNUnet.

I agree that telegram has a good UI but i fail to understand what that has to do with protocols. Unless you mean to also get the telegram server and change the whole thing to work over gnunet. Which at that point:

1. If you are running a seperate process to connect over localhost is it really p2p?

2. I wonder how much work it would take to convert it to GNS and gnunet because i bet there a whole lot of assumptions in there about DNS and servers and such. So maybe the effort wouldn't be worth it. Especially with how easy android or Gnome make it to have a beautiful UI (if the app is native).


Imagine your friends get an alternative Telegram client
from F-Droid and after a bit of negotiation they seamlessly
switch over to GNUnet, away from the cloud. The only aspect
I don't like is that Telegram is already attracting those
who need privacy for the most wrong reasons.


[1] https://about.psyc.eu/XMPP#Technical_Problems_with_XMPP
[2] https://telegram.org

Regarding your technical problems article some remarks:

- XMPP can have framing if done over websockets. So thats not a compromise you have to make anymore if you want framing.

- XMPP can work over Radio with 75 bits/s and minutes of reliability. Its not the most efficient that exists but if you have less bandwidth than radio you can use something else i guess :)

- Streaming parsers exist

- For binary transfer I am looking into Eris or EXI personally

- The huge rooms problem is actually about presence not anything to do with the protocol. There are two solutions to this:

1. Disable presence in rooms above a couple thousand people

2. Change to MIX the new way to do group chats in xmpp that is more scalable.

- The multicasting part looks very interesting. Can you expand on how that would work in a distributed network like gnunet? Because it specifically mentions a server solution which we cannot afford here:

> In PSYC, by contrast, the server will contact a set of servers, which will forward the news to another set of servers each, until all the recipients receive the news

- for an up to date xmpp server count you can see here https://xmppnetwork.goodbytes.im/webgl.html :)

its opt-in tho so not every server is there.


To keep this short your document there seems to be more than 15(!) years ago. So please link up to date versions in the future because XMPP its still being updated. Also lot of the links are dead too.


MSavoritias


reply via email to

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