Lemmy feature request: Show my negative “karma” in my profile page. You can make it opt-in if you must.

  • 0 Posts
  • 35 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2025

help-circle





  • I’m not even saying ditch the phone just minimize usage of it

    This is the correct take.

    I never used the Graphene meme and the shit American Baidu hardware it runs on (security and phone were always an oxymoron regardless). But I was on custom ROMs from around CyanogenMod 3 until Lineage 21. I also owned phones with the highest-end Snapdragon SoC’s.

    Over the years, I went from everything unlocked in the open, to “hiding root” to disabling root (I realized I didn’t even need it anymore). And now I deliberately downgraded to a lower-end phone running stock ROM. And even with that, there is an APP from a utility company that refuses to run because the phone has an unlocked bootloader, which was needed to properly recover the phone. So my next phone will be completely stock. Never again.


    Most people here tend to be on the younger side. So while their hearts are in the right place, and tend to agree with a lot of genuinely good stuff. They are also very susceptible to falling for memes and becoming a part of circle jerks (they are still r*dditors at heart after all). They also just lack maturity and experience to be able to value situations with less emotion and wishful thinking, and more nuance.

    And I didn’t even mention the fact that 📲 is actually their primary online device 🥲.


  • I2P is a fully connected network where everyone is a relay, a UDP transport exists iirc, and there are many other significant technical differences.

    And if you’re dreaming of significant masses moving to the shadows, you might as well dream of them using distributed solutions. Otherwise, the monsters will simply find and shutdown the hosts/servers of whatever the good kids are consuming.

    There is a connection between August and freedom. Do you know what is it?


    • The way to the provider does account auth varies.
    • The API for getting e.g. server list info varies.
    • Configuration generation varies.
    • Implementation choices for the VPN protocols varies (e.g. which user-space wireguard implementation to use if the kernel one is not usable for some reason).
    • Some features would require some scripting/light programming if not implemented by the provider. Not only is that asking for a lot, but errors here can be catastrophic.
    • …etc

    All that, and we didn’t even talk about user experience 😉.

    Having said all that, if you’re not using a service that offers configuration generation, which allows you to use your own clients, you’re doing it wrong.

    I use one of the services from your list. And beyond private key generation, I do everything with simple scripts on desktop (or using “protocol” clients on mobile). This is trivial since the server list with its addresses and public keys is publicly available as JSON, even without auth. So putting that info and my private key(s) together, I can actually generate all the configs I want myself with ease.

    But that’s just me. And providers would go broke if they only catered to the likes of me.



  • Zig is too irrelevant, both technically and adoption wise, for anyone actually relevant to be fighting over it. The number of notable Zig projects went from 3.5 to 2.5 recently 😉. Hell, Zig probably has more adoption as a build tool, than as an actual implementation language (I would take it over CMake any day of the month tbf).

    Hell, WIP languages experimenting with effect systems and/or similar next-gen concepts will probably hit v1.0 before Andrew thinks Zig is ready for a v1.0, which is in his forte, but no one should be holding their breath if they are not aware of some history and personality details. Since Andrew tagged Zig v0.1, the Rust project designed the edition mechanism, introduced three inter-compatible editions (four if you include 2015), and managed on-schedule ~66 1.n minor releases, and in the process grew into a semi-popular language impacting almost every corner of the industry.



  • The real news is that iroh hit v1.0.0.

    noq is a fork of crate that implements QUIC which iroh uses. In other words, it’s a minute implementation detail not immediately relevant at all to people who don’t even know what iroh is (yet).

    How did we get here? OP text is copied verbatim from the README, with the presumption that it’s relevant, but it isn’t.

    How did that happen? I would assume no human was directly involved in doing that, which would be par for the course with that shit-reposting account.



  • So I gave the actual code a one minute look (literally).

    Picked src/radicle/util.c, since that was the last file touched.

    The level of defensive programming doesn’t look that good (and I’m trying to be nice here).

    Here is an example, and note that I didn’t do C in a while:

    #include <stdio.h>
    #include <string.h>
    
    void rad_rstrip_nl(char* str) {
        int len_str = strlen(str);
        if (str[len_str-1]=='\n') {
          str[len_str-1] = 0;
        }
    }
    
    bool rad_get_input (char* str, size_t bufsiz) {
        if (!fgets(str,bufsiz,stdin)) return false;
        rad_rstrip_nl(str);
        return true;
    }
    
    int main() {
      char a[] = {0,0,0,0};
      bool i = rad_get_input(a, 4);
      printf("%lu\n", strlen(a));
      rad_rstrip_nl(a);
      return i;
    }
    

    The two functions above main() are copy-pasted from that file.

    Let’s zoom in:

    int len_str = strlen(str);
    if (str[len_str-1]=='\n') {
    

    Here we’re accessing str[len_str-1] without checking len_str first.

    But you might be thinking, maybe len_str can’t be zero!

    Let’s compile first with the AddressSanitizer enabled:

    # compile
    % gcc -Wall -fsanitize=address t.c -o t
    

    Now let’s see how easily we can have fun:

     % echo -n '\0' | ./t
    =================================================================
    ==2949689==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ba827af001f at pc 0x56032434d259 bp 0x7fff1d199010 sp 0x7fff1d199000
    READ of size 1 at 0x7ba827af001f thread T0
        #0 0x56032434d258 in rad_rstrip_nl (/tmp/t+0x1258) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
        #1 0x56032434d311 in rad_get_input (/tmp/t+0x1311) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
        #2 0x56032434d3e4 in main (/tmp/t+0x13e4) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
        #3 0x7fa82a227740  (/usr/lib/libc.so.6+0x27740) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049)
        #4 0x7fa82a227878 in __libc_start_main (/usr/lib/libc.so.6+0x27878) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049)
        #5 0x56032434d124 in _start (/tmp/t+0x1124) (BuildId: 1ee68e4d67960002de80ae290c8811c63f94aa51)
    

    (The rest of AddressSanitizer output omitted.)

    Another function from the same file:

    char* rad_strcpy (char* out, const char* inp, int from, int len) {
        const char* inp_shifted = inp+from;
        int len_inp_shifted = strlen(inp_shifted);
        if (len <= len_inp_shifted) {
    	memcpy(out,inp,len);
    	out[len] = 0;
        }
        else {
    	memcpy(out,inp,len_inp_shifted);
    	out[len_inp_shifted] = 0;
        }
        return out;
    }
    

    Here, inp is shifted before inp length is checked, which doesn’t look safe. But my one minute is up, so I didn’t dive into the function callers.


    Pretending C is a good choice in 2026, then not being extra vigilant with defensive programming, is not a good look. I remember myself being more vigilant in my wrappers even when I was a beginner.

    This is made worse by the developer repeating literal memes like:

    One issue I have with rust is that it adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain

    Maybe such an enlightened developer should know that you can bootstrap rustc from mrustc using GCC.


  • Most tor peers are not relays. So no, tor’s network capacity doesn’t auto-scale with more users, even when you’re sticking to hidden services.

    And you didn’t argue for anonymity from the start. And anonymity is a BIG argument, with bigger design implications than you think.

    Original Freenet (now called Hyphanet) predates both bittorrent and tor. And it’s one early example (and not the only one btw) of how you properly combine anonymous storage with anonymous transport (content addressing too, but that’s more of a jibe against the IPFS meme). It’s also (relatively) slow, and that’s actually intentional, at least in part, because speed can hurt your anonymity (the details are too technical, and that’s not the place to delve into them).

    Bittorrent didn’t lack (native) anonymity because the idea/tech was impossible to imagine. Anonymity didn’t come into the picture because availability and speed were the priorities. The protocol didn’t have encryption from the start either (or sub-piece downloading, or DHT, or PEX, or udp trackers, or uTP transport, but I digress).



  • How do you send a threat to an IP address? 😏 about supposed push of code encrypted no less. Unless, you’re thinking ISP involvement, that would be a hilarious (single) e-mail to read (from the “lawyer” to the ISP, because there will be no other correspondence).

    If the threat model is “lawyer”, developers will be fine. If it’s a “state actor” and/or all users need protection, then again, this is a whole other conversation. If it’s something in between, then yes, maybe developers/publishers should specifically be careful, and/or maybe the design of the software should help them, but without compromising the performance of the whole network. But again, bittorrent will not be the right protocol for this anyway.


  • P2P already gives you anti-censorship. Publisher anonymity shouldn’t be hard for developers to achieve either.

    If full network anonymity is desirable, then you would need a full top-down design to do it properly, and this becomes a whole different conversation (and the choice of using bittorrent itself will have to be revisited). But really, I don’t think that’s needed here.

    Pluggable transports can still be useful for varying reasons of course. I don’t think anyone would argue against them.

    But I would still opine that forcing a slow network on any forge alternative is the fastest way to keep 99% of potential users away.