• 0 Posts
  • 61 Comments
Joined 3 years ago
cake
Cake day: June 25th, 2023

help-circle

  • heck if anything, the Fediverse, as it is right now, is more susceptible to this. You can spin up spam instances on new domains, with spam users, and have them federate to existing instances, faster than volunteer run instances can ban/defederate.

    So you end up with not federating by default, but having some trusted web of instances that federate and maybe an approval process for new instances to federate with? But that’ll still lead to centralization with “trusted” instances and new instances having a hard time to join the club (there’s also the scaling problem of the fediverse, but that’s besides the point). So you end up with a few very big instances and the owners of those instances having all the power. Or maybe small isolated islands of mutually trusting instances? Still better than tech oligopoly, but also a far cry from the original dream.



  • Yes. And that requires the participants to self-regulate and be educated, at least beyond a certain number of participants (and this number is more in the 100’s than 1000’s of devices in a city size area).

    In case anyone is interested, in meshtastic, for a regular handheld device, set it to client if in a less populated area, client_mute in densely populated areas. router/repeater only for really well positioned nodes (think top of a mountain, NOT top of a tall building), router_late for ok positioned nodes where there’s other, better router nodes around, but they can cover some dead zone that the better router ones don’t cover. And then there’s other like client_base for e.g. a rooftop node to help handheld devices inside the house reach outside. And follow the guidelines of your local area group/forum/whatever on number of hops, band to use etc.

    None of that is really complicated, but a lot of users will just buy a device, turn it on excitedly with default settings, see that messaging works and not dig deeper, and then worsen then network for everyone.

    With meshcore, there’s a repeater firmware and a client firmware, it’s not just a setting that can be selected in the app. Default is client, and switching to repeater mean reflashing the firmware. And more clients don’t really matter for the network, since they don’t repeat. So much less risk of an unwitting user worsening the network.

    And if anyone wants to play with this, all the devices should support both meshtastic and meshcore firmware, so you can play with both and see which you prefer.

    And if you’re curious why I prefer meshcore, these are all the nodes I was able to hear on meshtastic and meshcore, respectively, in the same location, with meshcore I can reach twice as far in each direction


  • I’m definitely not an expert radio operator or anything, but this is how I understood it.

    With Meshtastic, no, it actually gets worse beyond a certain point, especially in dense areas. Each radio rebroadcasts messages, so more message fill the air, causing more congestion. setting devices to client_mute (no rebroadcasting of messages) alleviates this to some extent, but most people don’t do that. In general, a few well placed nodes are better than a lot of clients.

    Meshcore with dedicated Repeater nodes alleviates that a bit, as a node is either a client that can originate messages, or a Repeater that can only rebroadcast. And it has a bit better routing protocol, reducing unnecessary duplicates in some cases.

    The radio band is license free in many countries, but there’s still some restriction, e.g. 10% duty cycle in my country, which means no radio can be sending more than 10% of the time (so 1 minute in every 10 minute window). That combined with (afaik) nodes only being able so send one message at a time limits how many messages can be in flight at an instant. And more clients increases background chatter from e.g. node announcements and duplicates, leading to further congestion. And in meshtastic, since packets “flood” out in all directions, and each node rebroadcasts again, and it’s not directional, all the packets travel all over the place when you send a message. You could have a packet traveling in circles between new nodes for a long time.

    E.g. in my region, originally the default for meshtastic was 7 hops on long range fast preset. That led to congestion so they switched to medium range fast, then recommended limiting hops to 5, and now ideally to 3, just so there’s less chatter and less utilisation of the channel. 3 hops is barely enough for me to get out of the city I live in. Meshcore also does floods, but also can keep track of paths so you can have a relayed connection along a specific path that does not flood out in all directions, along with putting up repeaters being a conscious and strategic choice by users, so you get something more like a dedicated highway of repeaters that are placed high up and can relay messages much better than some client down at street level could. And the hop limit is more like 64 (I think it can be higher but that’s what is set somewhere in the firmware). And repeaters are stationary, so they don’t need to announce themselves to the network that often (e.g. every 3 hours in meshtastic vs every 24-48 hours in mesh core). All of that means less channel utilization and longer reach.


  • I agree, that would be amazing. I also hope it will help with some truly local community building (no troll farms from halfway across the planet spamming shit). Weather stations are already possible with sensor nodes, and most big repeaters have weather data. Though not like weather forecasts or anything.

    The main issue would probably just be congestion, not even bandwidth. Once it’s used a lot, some packets will just be dropped due to congestion and you don’t get a reply at all.

    A bit less of a problem with meshcore, with meshtastic in densely populated areas most users still don’t set their devices to client_mute, causing unnecessary rebroadcasts and even more congestion. Though with enough adoptions maybe governments might lower their restrictions on duty cycle, allowing for more traffic.



  • Not a democrat or even american, so 🤷

    That’s not what I’m saying, OP asked an LLM for a legal opinion on what democrats could do. LLMs are terrible at legal questions/opinions. Of the things it says, if they were true and made legal sense, none of it would stop the current war any time soon, it’s stuff that would take years to figure out, by which time this likely has blown over for the next crisis.

    By all means, prosecute the fucker and his administration for everything and try and make his life hell. But asking an LLM for a legal opinion on what democrats could do seems like top grade cope/virtue signaling so someone can feel better going “see, there’s all these things they can do, but they don’t, so they’re in on it and bad”. when there’s enough valid reasons to think that about democrats without falling back on slop and there’s no shortage of valid criticism, nor valid actions they could take.







  • I think there’s still a lot of room to explore without abandoning the utopia setting. like we usually only see the spaceship stuff, but what about a more political drama taking place on member worlds, that kind of thing, i think it could be amazing.

    also, as you say, it’s been done for 60 years. Might as well do the same thing over again for a new generation that hasn’t seen tos/tng/ds9. They don’t know it yet, so it’s not overused, and the TOS audience wouldn’t be the target audience anyways. and could still explore new topics. the audience isn’t the same, our world isn’t the same, making the same show again would still not be boring as it be a completely different thing.

    Both approaches can work imo and have a place, without the need to go more dystopia.







  • I’m not really sure I follow.

    Just to be clear, I’m not justifying anything, and I’m not involved in those projects. But the examples I know concern LLMs customized/fine-tuned for clients for specific projects (so not used by others), and those clients asking to have confidence scores, people on our side saying that it’s possible but that it wouldn’t actually say anything about actual confidence/certainty, since the models don’t have any confidence metric beyond “how likely is the next token given these previous tokens” and the clients going “that’s fine, we want it anyways”.

    And if you ask me, LLMs shouldn’t be used for any of the stuff it’s used for there. It just cracks me up when the solution to “the lying machine is lying to me” is to ask the lying machine how much it’s lying. And when you tell them “it’ll lie about that too” they go “yeah, ok, that’s fine”.

    And making shit up is the whole functionality of LLMs, there’s nothing there other than that. It just can make shit up pretty well sometimes.