The fact that it needs to be stated means that it has cloud features.
Opt-in and "encrypted at rest" AKA actually encrypted are the correct defaults.
I'm also uninterested unless both the client and the server are made open-source, because terminals are a bread-and-butter program and there's just no way I'm getting locked into someone else's cloud for that.
But the specific sentence you've quoted is a strange thing from which to recoil, from where I'm sitting.
The point I got from that that it's unacceptable that it's keeping data on their servers. The issue wasn't that it's encrypted at rest - the issue was that they got data they need to encrypt to begin with.
The data pertains only to opt-in cloud features. Warp is local-first. Note that the closed beta collects some info, so if you're not comfortable with that, please wait until our open launch.
Our plan is to open source the Rust client code once it's more mature.
We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.
There are a lot of promising options for native UI, but none finished and mature. As of today, that number sounds like it is one more.
Druid as it exists today is not a great fit for what you're trying to do, as drawing on mac is all based on Core Graphics and Core Text. GPU-based drawing is the future, and we're working on that (piet-gpu), but it's not yet in a really usable state.
In any case, hope this goes well. It's clear to me that Rust-based UI is the most viable path to an Electron alternative in the future, and the more evidence we have for that, the better.
Thank you, Raph! We've been following your work on Druid quite closely for a while, it's very impressive.
You'd exactly right that's why we didn't pick Druid--we needed something that rendered on the GPU. We actually talk more about this decision in our "How Warp Works" blog post here: https://blog.warp.dev/how-warp-works/
You really don't have to accept contributions if the repo is open. You could simply disable issues and close all PRs with a comment explaining that you're not ready for contributions yet. You could even automate that with a Github Action or similar.
Developing in the open would make it easier to trust that you're not doing something nefarious. When I think about the kind of data that goes through my terminal on a day-to-day basis, I have to _know_ for sure that my terminal can be trusted. That makes Warp a non-starter for me until it's open source, which is really a shame because it looks fantastic.
It's definitely something we actively considered! You can find some more details about why we chose to implement our own UI framework here: https://blog.warp.dev/how-warp-works/. The tldr; for Druid is they don't support any GPU backend at all right now.
Super excited about both of these things. Will your text editing widget be part of that? Because I'd absolutely love it if a widget with capabilities similar to that of full on text editor (sublime/vs code, etc) became the standard "textarea widget".
https://xkcd.com/463/ Strictly speaking, your plan is better than the alternative of keeping it closed-source, yet someone is clearly doing their job horribly wrong.
Anything useful you produce will be community-maintained eventually, and your cloud product will vanish once you complete your amazing journey; anything in-between seems like rent-seeking. Meanwhile, your competitors are Free Software and can out-develop you.
If this was a better, generic, screen sharing solution, it might be awesome. But forcing people to use a specific terminal to work with others feels like it'll be a non-starter for most people. Not least given how rarely I've ever had a need to show anyone my terminal (despite having had solutions for it for literally decades via e.g. sharing screen or screen sharing all the way back to VNC and similar).
Our strategy here is to share sessions to the web, so collaborators don't need to download the app. It's fascinating how far utilities like screen will get you in functionality, but I agree it's really hard to get people on there.
My point in mentioning screen was rather that despite having had solutions that work for decades, that everyone I collaborate with knows how to use, I can literally count the number of times I've felt a need to share just a terminal window with someone, rather than e.g. a full screen, on two hands over the course of 25 years.
It's rare enough for me to have a need for sharing a screen, but sharing a single type of window would cover just a tiny proportion of those rare cases.
My tech stack is atypical enough in many respects that maybe others will find it more useful, but to me this seems like a couple of useful but easily copied features (the auto-complete), and some stuff I'd never use.
Assuming that it wasn’t a rhetorical question: I do.
I spend 1/3rd of my day in terminal emulators, and anything that reduces the number of stupid (normally memory corruption) crashes that interrupt my work is a legitimate value proposition for me.
Edit: This isn’t an endorsement of this particular product, to be clear. I don’t know anything about it, except that being written in a fast, memory safe language endears me to it.
Maybe it's the way I use it, but iTerm2 crashes (or hangs) fairly regularly for me on macOS. I usually need to restart it at least once a week, which means losing ~dozens of tabs with context in them.
I use urxvt on Linux, and I don't have any problems with it.
Edit: I should also mention that I see plenty of non-crashing, non-hanging bugs with iTerm2 that look like memory misuse to me: split-workspace mode (tiled with a text editor) causes wonky graphical errors, and I've seen what looked like buffer reuse artifacts when switching between monitors.
I have run across one - of maybe a dozen terminals I've tested because I'm difficult and have very specific requirements of a terminal - that crashes on weird input. I can't even remember which one it was, because I moved on, but odds are it was while testing unusual features like Sixel or ReGIS support.
It's been a while, but gnome-terminal on earlier gnome 3 releases used to segfault very frequently for me. It's the thing that finally made me seek out other terminal emulators
Alacritty's performance in day-to-day use is actually very underwhelming, I tried to use it but there was just so many little lags left and right I promptly switched back to urxvt
urxvt was my workhorse for years; And I tried Alacritty + a tmux configure that emulated urxvt's tabs. It wasn't quite all the way there, wezterm is another one that seems to work well and has slightly improved rendering over urxvt, and I'm pretty happy with it right now, though it has a lot more bells & whistles.
The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.
Can you explain your objection in more detail? It seems like a terminal offering some kind of real-time collaboration with team members is a reasonable thing to offer, and that if you have that feature then it's good that it's opt-in with encrypted data.
> the report says that they have "recently reconfirmed" the lair of one of the unicorns ridden by the ancient Korean King Tongmyong, founder of a kingdom which ruled parts of China and the Korean peninsula from the the 3rd century BC to 7th century AD.
https://www.theguardian.com/world/2012/nov/30/unicorn-lair-d...
I had no idea that terminals and Rust projects were such highly charged emotional territory, nor that either were danger zones which commonly ate your time, your money, or your attention.
Kind of seemed to me like just another project.
I guess the kids these days have to start at volume 10 with "hard no!" or "best ever!" to be heard. THAT is a fad.
I didn't downvote you, but it's certainly fine to pass on something you think is a fad. It's another thing to jump directly to the end of the emotion spectrum by saying "hard no". My comment wasn't about skipping shiny things, it was about being so vocally firm about the negative. That doesn't leave much room for reconsideration later.
What if the project turns out to not be a fad, and a month or six later more people are using it and loving it? How does a "hard no" person back down from their bold rejection? This is what I was talking about.
[meta] I think many people here are interested in learning Rust and they use upvote button to "bookmark" (should use favorite instead, until you have actually read the article) (sugg: add favorite link to the main page)
Also:
"All cloud features are opt-in. Data is encrypted at rest."
The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.