{
    "columns": ["id", "name", "age"],
    "rows": [
        [1, "bob", 44], [2, "alice", 7], ...
    ]
}

There ya go, problem solved without the unparseable ambiguity of CSV

Please stop using CSV.

I agree with everything this article said. A lot of software would work better if devs took the time to learn and appreciate XML. Many times I've found myself reinventing shit XML gives you for free.

...But at the same time, if I'm working on a developer-facing product of any kind, I know that choosing XML over JSON is going to turn a lot of people away.

What's your motivation? Why are you doing this? Do you hope to make money out of it, or do you have more altruistic intentions? Because if it's the latter, you're unfortunately not pulling it off this way. Anyone you convince to use this will have their data and privacy at risk, and nothing you've posted here gives me confidence that this will change no matter how much you continue to develop it. It's clear that you are out of your depth here. An LLM isn't going to fill the gap in knowledge and experience you'd need to pull this off successfully. There's no point continuing this discussion, especially if you're just acting as a middle man to ChatGPT.

If this was a side project you were doing for fun, I wouldn't care. But you've been going around pushing this on the fediverse and reddit, and seem to be trying to make money off of it. Giving you the benefit of the doubt, I'll assume you're a well-intentioned person led astray by a sycophantic LLM (which is very common) rather than a grifter.

XMPP

I made that mistake too. XMPP's app situation isn't pretty, and ime notifications don't ecen work on iOS half the time.

Delta Chat is where its at.

They're guilty of conspiracy against shareholder value. Seeing such heinous crimes makes me wish burning at the stake was still a valid form of punishment.

They add that “any discussion of the potential risks” to a child’s health “must also be balanced against the potential benefits” that come from “collective social capital” of such a union.

I wonder if they're also weighing the societal costs of having potentially serious birth defects in 10-15% of the population?

• Qualcomm said first class Linux support was something they were interested in
• The entire first generation came and went with no usable Linux on Snapdragon laptops

The second time's the charm?

javascript over the internet can be be intercepted by a network admin or ISP.

Let me introduce you to my good friend HTTPS, and PKI more broadly.

we step away from “iOS and Android” and enable users to run this on their platform-of-choice. generally, all “modern” operating systems support browsers out-the-box. users should be responsible with how they run this app: e.g. if you trust firefox more than chrome.

So is it about convenience, or security? You expect users to audit their multi-million LOC open source web browser and supply chain before using your app?

Browsers are notoriously not secure. Javascript is heavily sandboxed and access to operating system resources is heavily restricted, so attacks through there are relatively rare. However, attacks from the OS side are almost trivial execute. There's nothing the browser can do to protect its data if the OS falls into the hands of an attacker (eg malware or device confiscation)

im using the metered.ca turn servers because they have a free plan (more than enough when i limit it to only brokering p2p connections). you have the option to use your own api key to do things like enable a “relay-mode”, which will proxy all messages. using the api key is simple UI abstraction for users to configure a TURN/STUN server. im open to make this as configurable as nessesary if users want to add multiple of their own servers.

That doesn't solve the issue I brought up, which is that a state actor can trivially censor your app by attacking those servers. By contrast, blocking Delta chat would require them to block the entirety of Gmail, for example.

"reliable” is a relative term.

No. Your app is either reliable, or it isn't. A centralized service is vulnerable to being taken down, but that has nothing to do with reliability. The majority of internet traffic goes to centralized sites with 99.99%+ uptime.

IMO, a chat app that struggles to send or receive messages is a toy. It's like trying to use the Pine Phone as a daily driver if you're someone who actually needs to male phone calls every day. Except, pinephone's reliability issues are implementation details that theoretically could be fixed, whereas your app's are architectural that would require a redesign. That's partly why I brought up meshtastic, because it's at least a fun toy.

my app is speciafically based on webrtc, which has unparalelled transfer speeds; which is especially useful when sending large files.

Comments like this, and your apparent misunderstanding of basic HTTPS make me think you're just vibe coding all of this. WebRTC doesn't have "unparalleled" transfer speeds. That sounds like something ChatGPT would say. WebRTC is a just protocol designed to provide a simple way to do streaming in the browser, without requiring apps to build their own custom protocols on top of eg websockets. Using it for text messages is kind of absurd, because such an application doesn't fit the low latency/high bandwidth the protocol was designed for.

There's nothing wrong with vibe coding btw, you do you, but people need to stay fae away when security is involved.

For anyone reading this thread looking for a secure chat app, just use Delta Chat, or even Signal (which has some issues, but it's better than nothing). If you're feeling adventurous, look into meshtastic.

when now-XLibre developer Enrico Weigelt was making a lot of changes to the codebase that then ended up with a lot of that code being later reverted.

Looked this guy up, and apparently he's a right wing anti-vax nutjob who got yelled at by Linus Torvalds for spreading misinformation on the kernel mailing list.

Why do we have people like this?

Javascript over the internet is not secure - im investigating the to use service workers to cache the file.

Can you explain what you mean by this? What is not secure here?

How is this different to any other messaging app? - the key distinction between this project and other like it like signal and simpleX is that its presented as a PWA.

I don't see how this offers any security advantages? A PWA isn't any easier to uninstall than a native app if you're worried about someone catching you with the app installed. On the contrary, native apps can be hidden behind a custom pin on modern Android (and probably iOS), and PWA security is entirely at the mercy of whatever browser you installed it in.

P2P - so that it can be decentralized and not rely on a central server for exchanging messages. The project is using WebRTC to establish a p2p connection between browsers.

Most WebRTC connections still require a TURN/STUN server, meaning the infrastructure is effectively (and unavoidably for most people) centralized. That makes it less reliable and more vulnerable to being blocked than something like Delta Chat, which relies on the existing public email infrastructure. A state censor can't block Delta without blocking all email traffic (or the whole internet, like Iran and Cuba do lol), but they can block your TURN/STUN servers pretty easily.

Beyond that, P2P is inherently less reliable by its nature. IMO, this is only an acceptable tradeoff if you're going all in on mesh networking solutions (eg meshtastic), which I assume you're not. There are already secure messaging apps in that space, and it's not something the average joe will be able tp use.

Since they're both E2EE, there is no risk using the more centralized Delta over your P2P version. You just get to deal with the annoyances of P2P with no added benefits.

I don't do web development, but I dabbled a little with Tailwind CSS a while back and found it to be a really nice way to work. AFAIK, you can't do that in standard CSS without dedicating the time to design and write your own library of classes.

Yup. It seems CDPR were the Linux haters all along.