Did you happen to look into CephFS? CERN (folks that operate Large Hadron Collider) use it to store ~30PB of scientific data. Their analysis cluster is serving ~30GB/s reads
Sure, so the use case I have requires elastic storage and elastic compute. So CephFS really isn't a good fit in the cloud environment for that case. It would get prohibitively expensive.
Signal keeps cranking out brilliant crypto papers, but from a product perspective, it feels like they're throwing stuff at the wall to see what sticks. We've got post-quantum handshakes, stories and money transfer experiments, but still no SDK, no APIs, no bots. The official libsignal library is undocumented and incomplete. Large parts of functionality are still buried on clients. Don't get me started on "but they have published all protocol specs on their website, go on and roll your own library"! That's not how you run a product. It's borderline negligent for a platform used by millions.
Every other major messaging app exposes something to developers, but Signal is allergic to the idea. Makes me wonder if they even have a head of product because whatever they're doing now is a far cry from a coherent product strategy. Signal is basically a pile of hot cryptography duct-taped to a messenger that's more hostile than any product in Apple's walled garden. And that's from a day one user who's been advocating for them the whole way.
</rant> thanks to everyone involved in building the product <3
> Every other major messaging app exposes something to developers
Not iMessage, which is the largest messaging app in the US. Uniquely, it doesn't even have an android app, so android users have to pay $800 to buy a single-use device with an effectively worthless OS bundled on it just to be able to join group chats.
iMessage doesn't even have good crypto, the default settings include unencrypted iCloud backups of your iMessage data lol.
I'll take Signal, which works on my desktop linux machine and android phone, over iMessage any day of the week, but the US as a whole seems to have chosen differently
As far as I know, there isn’t an official API for cross-platform communication. However, the Messages framework allows developers to create sticker packs and interactive messages for iMessage. People in the group can interact with messages created by other apps, such as polls, location updates, and game integrations to name a few
Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock users into what signal believes is better for them. That's the whole "we love opensource but we won't merge your PRs and might lock your account out of the network for using forked clients that got rid of features like crypto that you might not like". I'm still sour for all the bad faith placating "the ecosystem is moving" post by Moxie and the lame excuse for not supporting federation. And no, I'm not finding it hard to onboard family and friends onto secure XMPP clients and accounts.
XMPP was a well intended idea but a bad protocol. Sure federation is good, but they needed a proper standard instead of making everything an optional extension that C2S and S2S never agree on. Like getting the right auth and encryption is even messier than on email.
Also, XML was the wrong choice. Pissed me off as a dev, back when I was doing stuff with ejabberd.
That's the kind of "compelling in theory, irrelevant in practice" comment I would make if I had no/obsolete experience with XMPP. It just works, with a healthy and thriving ecosystem of compatible client/server implementations developed independently by many organisations (small and large) around the world. At the user-level, it's just plug and play. As a developer, you don't even have to see any XML (you can deserialize your stanzas into whatever higher-level/prettier construct the programming language/stack your product depends on)
The argument that xmpp problems stem from XML format is the silliest of all: from 15 years of working with xmpp, we had all kinds of problems, but none of them were caused by XML format.
On the contrary, xmpp is a very good protocol. The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
Disclosure: my team and I are actively working on improving xmpp, but in a rather orthogonal direction to general XSF council route.
> The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
I think that's in the organic nature of protocols catching-up to changing goals and priorities, as the state of the art and the user needs evolve. I think it's pretty-well acknowledged by the XSF (and to a further extent by modernxmpp.org) by curating a short-list of XEPs and behaviours to implement.
I'm glad you aren't finding it hard. I can't even get people to move from Whatsapp and Messenger over to Signal. Only computer geeks seem to care or bother, so that's who is on my Signal list.
That's why I skip the Signal intermediate stage plain and simple: once Signal inevitably enshittifies (a property of centralised services), the people you painfully brought there will no longer kindly listen to you when, lesson learned, you will try to pull them into federated services.
For anyone else (i.e. the majority, which already has 2-5-10 messaging services on their device depending on how you count), quicksy.im does a decent job at emulating the onboarding experience of phone-based social graphs (WhatsApp & al.) and substantially lowers the barrier to being reachable over XMPP.
Counter argument: When the sole reason for existence for Signal is private/secure messaging, it makes sense to resist opening up to third party development.
That's a big can of worms that invariably will impact their ability to deliver on their main mission - private IM. Eg of problems: Who gets dev access, how do you vet plugins/aps from deceiving users, would users understand the risks, when an app gets compromised how to fight malicious campaign to discourage using Signal etc. etc.
Is this an important feature? I know WhatsApp and iMessage have some kind of API for businesses, but as a regular user, I've never interacted with a legit business using it. Only been harassed by bots a few times.
My one serious problem with Signal is that it silently goes out of date then stops sending notifications, so I miss messages entirely. Kind of its one job.
Maybe maybe not. I think it is a useful feature for power users. The question is if targeting power users will help mass appeal. I'd argue with an app like Signal, yes it would. The power users are effectively their evangelists. APIs could enable a lot of features that people are asking for like location sharing, bots (e.g. on your IOT devices), and so on. The concern is more that introducing those things creates security risks but I think that's okay. Put a "developer mode" type switch like in Android.
But there are also other things I'd like to see.
For mass appeal I'd like to see them integrating Signal Stickers[0] into the app so people can search stickers. This has been a surprisingly common complaint among people I've converted over.
For both groups I'd love to see something like this feature request[1] I like that it could serve as the backbone of a mesh network and AirDrop is a incredibly popular. Would be super cool if you could hold a copy of the APK on your phone and drop it over to others to install that way. I imagine even a rudimentary mesh network could really reduce server loads. My GF and I often sync pictures to each other this way. No reason that needs to go over the network when we're sitting 5 feet from one another.
For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone. It's not a cure all, but it greatly reduces the chances of "incriminating" evidence being found on my device. But such a feature seems quite unpopular on their forums (I am very much not a fan of their forums and the community there...)
> APIs could enable a lot of features that people are asking for like location sharing
Please, no. You don't need that as a feature when you can drop a maps link.
> it could serve as the backbone of a mesh network
????? What?
> For power users I'd love to see a nuking capability. Bidirectional. I want to know that if I am at a protest or something and get picked up by the Gestapo that either I or a trusted friend can wipe my phone.
If you are at a protest with your phone, you are very likely leaking enough signals intelligence to identify, analyze, and monitor you and the entire group you are/were in contact with.
To me? All of these requests sound like things that would make the app the exact opposite of what I am looking for. Right now it is damn near perfect.
This does not update over time. So it has some serious limitations. The feature is actually quite helpful when meeting up with others, especially on longer road trips. It's a good way to allow the other person to know when to expect me as well as them know if I'm safe or have had hiccups. Means I am not using my phone while driving.
> ????? What?
For that link the user was talking about sending multimedia directly between devices, like "Airdrop". Why stop at pictures and videos? Why not texts? If these are short range then why send over the servers? It saves Signal server costs as well as provides some extra privacy and security for users as their messages cannot be gobbled up over the network (you'd have to be physically in range). Capture and decrypt later (the motivation Post-Quantum resistance, as discussed in the Signal blog post) can't be done if you don't capture, right?
There is real desire to still be able to communicate at times when networks are down. Be that a natural disaster, a crowded/congested area, or a government shutdown. Means of passing digital media during such events is still critical. It's not like we pass each other physical notes anymore. Plus, behind a secure protocol that's a bonus.
> If you are at a protest with your phone
Yeah sure, but reducing signals and information leakage is better than not reducing, right? Privacy and security are not binary things, they are continuums.
> To me?
Why?
Do these things stop you from using the app the way you currently use it?
I feel you. The "stories" feature especially felt like "throwing stuff at the wall to see what sticks." Given that they're a nonprofit founded by an anarchist, I assume their goals are just different from the typical product-focused company? Which I'm fine with, the app does what it's supposed to do. It would be lovely to have an SDK though.
Are you referring to the json macro that allows variable interpolation? Doing that will void type safety. Might be useful in dynamic languages like Python but I wouldn’t want to trade type safety for some syntactic sugar in Go
I was aware of Supabase, but still was confused as to what this project actually does. The mention of "1 file" and "app server" wasn’t helpful either. Does that mean a single binary? One SQLite file? Does it execute other binaries? I’m not sure. In contrast, when I visited the PocketBase website - it provided a much clearer explanation of its purpose.
The GitHub security alert digest[1] is a real thing. It's a feature of GitHub where they report security vulnerabilities in your project's dependencies. For example, if you use python and you have specified requests library in your requirements.txt, GitHub will send you emails about disclosed vulnerabilities in that library, urging you to upgrade to a higher version where it's fixed.
I find it confusing that author proposes llms.txt, but the content is actually markdown? I get that they tried to follow the convention, but then why not make it a simple text file like the robots.txt is?
Yes, and .py is "plain" text too. The extension however helps with signaling the intend of the file. Also, there is something to say for the argument "there is no such thing as plain text" [0]
If you had python code and you didn't want it to have syntax highlighting or be run/imported or any of the other normal things that you do with python files, it might make sense to have python code in a .txt. file.
Same idea here IMO. .md would signal the wrong intent, as you don't want to render it to markdown formatting or read as a markdown file normally is. You want it to be read as plain unrendered text.
Creative solution to a problem they had - no job and apparently only a backpack to their name, but the story quickly fell appart when I realised that they bought delivery robots, laser engravers, clothing, seals, double digit ipads, etc. Clearly they are loaded and just trying to downplay their invasion of privacy and perhaps downright illegal cloning of voice and appearance to get a job. Good job on that one company calling them out.
Agree, I got some anxiety thinking of the security implications of being handed an ipad of unknown source.
We are slowly getting to a place where people realize a USB-drive found in the parking lot should be met with suspicion. But target one of the higher-ups with an ipad didn't raise eyebrows? (maybe it did, hope so)
> Infrastructure teams can usually implement a feature faster than every app team in a company, so this tends to get solved by them.
Well, that's comparing apples to oranges. Product teams have completely different goals, e.g. adoption/retention/engagement, so naturally internal cluster encryption is so far out of scope that in fact only the platform team can reasonably implement it. I don't see how that statement is relevant. You don't send an electrician to build a brick wall
Application security should be everyone's responsibility. Architects, developers, and operations.
Too many times have I seen architects and developers completely ignore it to make their jobs easier, leaving it to operations/infrastructure to implement. It's easy to twist the arm of business people with a "I can't ship feature X if you want me to look at security Y".
If everyone took this seriously perhaps we would have fewer issues.
I agree, I was just making a point that different teams have different priorities and thus different scope. Saying "PodA can only talk to PodB over mTLS" is very different to "Users need to login using oauth". Who is going to build the product if product team is working on the service mesh?
you can implement mtls (and almost all the other service mesh features) without service meshes, and it's usually better because of lower overhead, less total complexity (see for example the fat client libraries in use by google, netflix, etc.). but people don't want to think about this so leave it to infra teams to plaster a service mesh over everything.
You can, but it's absolutely a pain in the neck. Services need to load the certs from the filesystem on boot-up and trust the certs provided by other services. To manage trust, you need a certificate authority. Now you need to load the certificate authority's cert, and you need to manage rotation of certs. You need to help developers set up laptop-local certificate authorities and get them to issue certs so that you have Dev/Prod parity. You need to ensure that developers are enforcing modern ciphersuites, not doing bullshit "insecure-skip-verify" kind of toggles that make their jobs easier (because remember, their job isn't security, it's shipping features), not accepting self-signed certs or other certs not signed by the certificate authority. You need to make sure all this stuff is put in the testing suite to make sure it keeps getting maintained, and you need the files for these tests marked in CODEOWNERS to be under InfoSec control to ensure nobody rips them out just because they're inconvenient. And you need to copy this for every single service you run in production and every single development team.
You know what else you can do? Write your own web server (/sarcasm). I mean, who needs nginx? Probably writing your own will have lower overhead and less total complexity, not running a bunch of features that you don't use. And probably it will not be anywhere close to as good as a battle-hardened web server used by millions of engineers that gets regular support.
Personally I think it's debatable whether services really need mTLS within a private network. It's mostly a question of what scale you're running at; probably there's higher benefit-to-effort-ratio InfoSec projects to tackle. But if you do decide you need it, unless you can prove that the overhead is unworkable for your requirements, really you need to bite the bullet and put in a service mesh.
Yes, traffic between generic service and the mesh entrypoint is clear text BUT since the proxy is in a sidecar of the generic service pod, it shares the same "localhost" by mean of Linux network namespaces, so it's virtually isolated (if there isn't a bug) from other code running on the same node. When it exits the pod localhost, traffic is already encrypted.
