4 ms·

Mh, XMPP is well known, open, far lighter than IPFS... Why the hell I'd want a MONSTER software just to chat knowing that "real security" of such giants is far

by kkfx 3y ago

Mh, XMPP is well known, open, far lighter than IPFS... Why the hell I'd want a MONSTER software just to chat knowing that "real security" of such giants is far theoretical since they are so big that their knowability is limited for anyone and attack surface is enormous? Dear devs I know some tech are trendy, but please focus on good tech, not monsters. For socials we have Usenet, today antispam can handle the task, and the rest while from another era works well enough. For chat we have IRC and XMPP, with the latter far more modern, featuresful and still simple enough, we have mails. Sharing files is still complex but syncthing works for mere exchange, ZeroNet is good enough for simple distributed web. We have enough crappy monsters from the commercial big tech world to add others.

jstanley 3y ago
In what way is ipfs a monster? It is a single go binary that does a tiny number of jobs.
- Grimburger 3y ago
  Client side compute for other random people is probably what GP is talking about here.
  - jstanley 3y ago
    IPFS doesn't do that, are you thinking of something else?
    - Grimburger 3y ago
      https://discuss.ipfs.tech/t/high-bandwidth-and-cpu-usage-from-go-ipfs/13982 https://discuss.ipfs.tech/t/high-bandwidth-and-cpu-usage-fro...
- kkfx 3y ago
  Did you try to look at IPFS codebase size?
  - jstanley 3y ago
    ~/kubo$ find . -name \*.go | xargs wc -l | tail -1 59629 total Doesn't seem that big?
    - kkfx 3y ago
      YES! Compared to a simple IRC server+client or XMPP definitively.
      - jstanley 3y ago
        Well irssi is an IRC client and is bigger than that: ~/irssi$ find . -name \*.[ch] | xargs wc -l | tail -1 88551 total https://github.com/irssi/irssi https://github.com/irssi/irssi Obviously ipfs doesn't have the chat UI, ipfs is just a protocol layer. But it is a more complicated protocol than IRC, so you'd expect it to be larger. I don't think it's large out of proportion, certainly not large enough to call it a "MONSTER software".
      - bogwog 3y ago
        My users complain all the time about the LoC of my codebase
    - mrusme 3y ago
      I'd like to point out that you probably cloned https://github.com/ipfs/kubo https://github.com/ipfs/kubo there, which is only one part of what accounts for the "IPFS codebase". If you want to find out the actual LoC, I'm afraid you will need to dig through https://github.com/ipfs/kubo/blob/master/go.mod https://github.com/ipfs/kubo/blob/master/go.mod and pick everything that's github.com/ipfs/*, github.com/libp2p/* and github.com/ipld/*.
      - jstanley 3y ago
        Fair point!
- jeroenhd 3y ago
  IPFS is a resource hog. Not sure if it's just the implementation or if it's because of architectural limitations, but it gobbles up CPU and RAM much more than you'd expect it to. I shut down my self-hosted IPFS server because it kept pegging a CPU core doing what seemed like nothing (no new pins, barely any network traffic, just sitting there).
  - holmesworcester 3y ago
    (Quiet founder here) Yes, IPFS is a resource hog when running on the global IPFS network, but Quiet never touches that network, and this improves performance a lot. I can run Quiet in the background all day on my Pixel 6 and we haven't even started optimizing for battery life yet.
komali2 3y ago
Well, XMPP is nice, but ZeroNet also seems like a monster.
thfuran 3y ago
>For socials we have Usenet, [...] For chat we have IRC You can't be serious. Should we abandon displayport because we have vga?
- kkfx 3y ago
  it's not the same: IRC or XMPP are very small piece of sw compared to IPFS alone. While for messaging do essentially the same: why using a many hundred of megabyte app when a 10Mb one can do the same?
  - holmesworcester 3y ago
    (Quiet founder here) We love XMPP and IRC, but both IRC and XMPP require servers, and most people don't have a server or even a friend who has a server, so they depend on Google, Facebook, etc. There may be work in the XMPP space on a pure p2p XMPP, but based on my conversations with folks in the (awesome) XMPP scene last year at FOSDEM, it was pretty experimental and there were major problems they hadn't tackled yet, like identity. Quiet is an effort to make a chat app that works well out of the box without depending on a server (or a company.) This feels new, different, and helpful to the world right now! And achieving this goal feels worth loading a few MB of dependencies or even (gasp! wince!) Electron :)
    - MattJ100 3y ago
      I remember chatting with you at FOSDEM (Snikket dev here). Congratulations on the launch! Generally I agree that the goals of Quiet are sufficiently different to the way XMPP is used/deployed today that your entirely different stack is warranted. While people do use XMPP with Tor today, and I'd like to add native Tor support to Snikket at some point, I don't envision that ever working the way Quiet does. Nevertheless, an XMPP<->Quiet bridge would be a fun project for someone, some day :)
    - kkfx 3y ago
      Thanks for sharing them :-) > most people don't have a server or even a friend who has a server, That's wrong from my point of view. In the past, in the dialup era that's normal, but we are in the fiber optic broadband era, at least in vast part of the world who are essentially the parts where IT is developed and used, so it's wrong not to have an IPv6 static global per device, it's wrong not having a domain name per human being, at least per Netizen. Correcting this is anyway needed because even with modern connections distributed solutions have too much overhead, too little performances to be generally used. Having a homeserver, a direct connection with own devices, from cars to "smart" water heater should be normal for those who want it, normal without intermediaries but still with server, we need to know our infra. Building giant tools to circumvent actual state of things is technically fascinating, give end user a friendly UI is remarkable but it does not really solve the background problem: giants services will be much more performant. On contrary no giant can offer something more effective than a direct connected services for any user, from a single device with data and logic and UI on it, to LAN to generic P2P connection without extra overhead. As a small example no VoIP services can be faster in my LAN than my local softphones/deskphones talking each others. No GMail alike service can search faster than my local notmuch-emacs on local maildirs. No file sharing services to exchange a file can be faster than a direct connection between someone else and me, at the maximum extreme they can be nearly equivalent. At least, that's my vision: no chance to win competing with big & powerful on such tech, some chances pushing a local first, wide open connection between peers for the rest because users are needed, but nerd, people who know what they use is even more needed to start, just understanding IPFS from it's code and "docs" is challenging, understanding IRC is far simpler.

by kkfx 3y ago

jstanley 3y ago

In what way is ipfs a monster? It is a single go binary that does a tiny number of jobs.

Grimburger 3y ago
Client side compute for other random people is probably what GP is talking about here.
- jstanley 3y ago
  IPFS doesn't do that, are you thinking of something else?
  - Grimburger 3y ago
    https://discuss.ipfs.tech/t/high-bandwidth-and-cpu-usage-from-go-ipfs/13982 https://discuss.ipfs.tech/t/high-bandwidth-and-cpu-usage-fro...
kkfx 3y ago
Did you try to look at IPFS codebase size?
- jstanley 3y ago
  ~/kubo$ find . -name \*.go | xargs wc -l | tail -1 59629 total Doesn't seem that big?
  - kkfx 3y ago
    YES! Compared to a simple IRC server+client or XMPP definitively.
    - jstanley 3y ago
      Well irssi is an IRC client and is bigger than that: ~/irssi$ find . -name \*.[ch] | xargs wc -l | tail -1 88551 total https://github.com/irssi/irssi https://github.com/irssi/irssi Obviously ipfs doesn't have the chat UI, ipfs is just a protocol layer. But it is a more complicated protocol than IRC, so you'd expect it to be larger. I don't think it's large out of proportion, certainly not large enough to call it a "MONSTER software".
    - bogwog 3y ago
      My users complain all the time about the LoC of my codebase
  - mrusme 3y ago
    I'd like to point out that you probably cloned https://github.com/ipfs/kubo https://github.com/ipfs/kubo there, which is only one part of what accounts for the "IPFS codebase". If you want to find out the actual LoC, I'm afraid you will need to dig through https://github.com/ipfs/kubo/blob/master/go.mod https://github.com/ipfs/kubo/blob/master/go.mod and pick everything that's github.com/ipfs/*, github.com/libp2p/* and github.com/ipld/*.
    - jstanley 3y ago
      Fair point!
jeroenhd 3y ago
IPFS is a resource hog. Not sure if it's just the implementation or if it's because of architectural limitations, but it gobbles up CPU and RAM much more than you'd expect it to. I shut down my self-hosted IPFS server because it kept pegging a CPU core doing what seemed like nothing (no new pins, barely any network traffic, just sitting there).
- holmesworcester 3y ago
  (Quiet founder here) Yes, IPFS is a resource hog when running on the global IPFS network, but Quiet never touches that network, and this improves performance a lot. I can run Quiet in the background all day on my Pixel 6 and we haven't even started optimizing for battery life yet.

komali2 3y ago

Well, XMPP is nice, but ZeroNet also seems like a monster.

thfuran 3y ago

>For socials we have Usenet, [...] For chat we have IRC You can't be serious. Should we abandon displayport because we have vga?

kkfx 3y ago
it's not the same: IRC or XMPP are very small piece of sw compared to IPFS alone. While for messaging do essentially the same: why using a many hundred of megabyte app when a 10Mb one can do the same?
- holmesworcester 3y ago
  (Quiet founder here) We love XMPP and IRC, but both IRC and XMPP require servers, and most people don't have a server or even a friend who has a server, so they depend on Google, Facebook, etc. There may be work in the XMPP space on a pure p2p XMPP, but based on my conversations with folks in the (awesome) XMPP scene last year at FOSDEM, it was pretty experimental and there were major problems they hadn't tackled yet, like identity. Quiet is an effort to make a chat app that works well out of the box without depending on a server (or a company.) This feels new, different, and helpful to the world right now! And achieving this goal feels worth loading a few MB of dependencies or even (gasp! wince!) Electron :)
  - MattJ100 3y ago
    I remember chatting with you at FOSDEM (Snikket dev here). Congratulations on the launch! Generally I agree that the goals of Quiet are sufficiently different to the way XMPP is used/deployed today that your entirely different stack is warranted. While people do use XMPP with Tor today, and I'd like to add native Tor support to Snikket at some point, I don't envision that ever working the way Quiet does. Nevertheless, an XMPP<->Quiet bridge would be a fun project for someone, some day :)
  - kkfx 3y ago
    Thanks for sharing them :-) > most people don't have a server or even a friend who has a server, That's wrong from my point of view. In the past, in the dialup era that's normal, but we are in the fiber optic broadband era, at least in vast part of the world who are essentially the parts where IT is developed and used, so it's wrong not to have an IPv6 static global per device, it's wrong not having a domain name per human being, at least per Netizen. Correcting this is anyway needed because even with modern connections distributed solutions have too much overhead, too little performances to be generally used. Having a homeserver, a direct connection with own devices, from cars to "smart" water heater should be normal for those who want it, normal without intermediaries but still with server, we need to know our infra. Building giant tools to circumvent actual state of things is technically fascinating, give end user a friendly UI is remarkable but it does not really solve the background problem: giants services will be much more performant. On contrary no giant can offer something more effective than a direct connected services for any user, from a single device with data and logic and UI on it, to LAN to generic P2P connection without extra overhead. As a small example no VoIP services can be faster in my LAN than my local softphones/deskphones talking each others. No GMail alike service can search faster than my local notmuch-emacs on local maildirs. No file sharing services to exchange a file can be faster than a direct connection between someone else and me, at the maximum extreme they can be nearly equivalent. At least, that's my vision: no chance to win competing with big & powerful on such tech, some chances pushing a local first, wide open connection between peers for the rest because users are needed, but nerd, people who know what they use is even more needed to start, just understanding IPFS from it's code and "docs" is challenging, understanding IRC is far simpler.