Sven Slootweg @joepie91@pixie.town

An internal conflict that I haven't found an answer to yet, is how any sort of 'universal solution' in tech, however alluring it is on the surface, is fundamentally incompatible with ethical boundaries.

"Packaging everything" means also packaging software that kills people.

"Interoperating with everything" means also interoperating with systems run by bigots for the purpose of harming others.

"Works for everyone" means it also works for oppressors who wish to use it to oppress others.

At the same time, there are good ethical reasons to aim for universality (and do it properly): it increases the chances that your thing will work for (marginalized) people who you might not even be aware exist, and who are constantly left out in the cold by the assumptions made by most systems.

Like, yeah, it's true that the tech doesn't really work. But that's... really not the main problem with it? You're actually going to have to engage on the topic of exploitation to get the point across, there are no shortcuts here

The problem with arguing against LLMs like ChatGPT purely on the basis that they "don't work", is that it might *seem* like an easier argument to convince people, but in practice you've just specified the threshold of workingness at which exploitation is acceptable

"But I know what part is relevant!"

If you really knew where the problem was, then you would likely already have found it. And to be clear, there's nothing wrong with needing help to find an error, but you *do* need to acknowledge that that limits your ability to determine relevancy of different parts of the code, and leave that job to whoever is helping you with it!

It really doesn't matter how often and empathically you ask people to share the entirety of the code that they are asking for help with; they'll still try to "extract the relevant parts" to "help".

Like, I understand that it is with good intentions, but please please *please* just give me the full unmodified code. Reading 'unnecessary' code costs me orders of magnitude less time and energy than an extensive back-and-forth to figure out which crucial part you cut out (which you thought was not relevant, but was relevant after all).

To be clear: that doesn't mean that there can't be legitimate reasons to give up on a system and create something else. Governance issues, for example, are a real problem.

But such a decision should have specific *reasons*, and doesn't remove the need for collaboration - go organize a new thing with a couple of people from other projects who think about the problem space similarly!

I will probably do a 'proper' full-size blogpost about this at some point, but for now this will have to do.

It saddens me immensely to see the tendency across the whole FOSS world to respond to issues with chat/code/etc. by proposing to just... move to a different one, that may or may not be open (and often isn't).

Is FOSS not supposed to be about collectively building open infrastructure, including our own meta-infrastructure? About removing that dependency on proprietary, user-hostile systems, such that we have the collective freedom to use our computers as we see fit, and collectively benefit from working together on that goal?

Then how is it justifiable to respond to platform and tech issues with "let's just use something else, we don't have time/money to fix this", when we *could* also be organizing across projects to all pitch in some work to improve the open thing? Where's the solidarity? Where's the collaboration? Where are all those ideals that people always talk about?

Some more details:
- Body is probably under 2cm long
- Non-aggressive, runs away when it thinks it's been spotted
- I'm in the southern Netherlands

What kind of spider is this?

Update: I've potentially found someone! You can still apply in case that doesn't go through, but most likely the job will be taken.

I'm looking to pay someone who enjoys #Rust to do the following things for me:

1. Write some rough documentation on the #Veilid API and how to use it; a list of notes, some self-contained example code, basically anything that shows it at a high level and explains what the different parts are for.

Format is up to you as long as it's clearly understandable and sufficiently complete.

2. Write Node.js bindings for that API, using something like Neon. They don't have to be super well-designed, they can be a 1:1 correspondence, as long as the whole API is realistically usable from the JS side.

This is blocking some of my other projects, and I don't have the spoons to do these things myself, so before responding, please make sure that you would actually have the spoons to complete this! Payment will be upfront.

This is for personal projects, so I'll be paying for this from my own (limited) money - it'll be a one-off freelance thing, and there's unlikely to be any future work coming from it. Just want to be upfront about that.

The result will be used in WTFPL/CC0-licensed projects, so should be compatible with that, ideally under the same license. Those projects themselves will be explicitly non-commercial.

If you'd prefer to contribute it to the Veilid project directly (assuming they are interested in that), that would be fine too, as long as it unblocks my projects :)

It would be nice if you have some sort of past work to show, but I don't care about resumes (and marginalized folks will have priority). Either Matrix or IRC works for me to communicate.

I don't know what this sort of thing would cost, so please let me know what you'd charge for it, and then I can make a final decision on whether I can afford it or not.