Mike St Johns talked about DNSSEC bootstrap timers in the context of a VM on the shelf, brought live 4+ years later: how do you update the Trust Anchor for a cold VM image which is very old?
I'd go one step further, and say offline is just real-time with extreme latency. This is what we realized when re-tooling our app for offline use – anything we build that enables offline use will by its nature enable real-time collaboration.
When you do not rely on ACID for data consistency, you need to architect for eventual consistency. For example CRDT on collaborative editing a text document.
I don't think "Offline Is Just Online with Extreme Latency" is a useful concept because it doesn't encapsulate the key difference: pessimistic or optimistic UI.
For example, say you have a form. If you built it thinking online first you'll probably have some pessimistic UI which shows a spinner and waits for the server to respond with ok/error. You can't simply think, okay since we're offline, more latency -> show spinner for longer. You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online.
In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.
> You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online.
Isn't that exactly what the article argues for though?
> This kind of idea would move you away from a product full of API calls to one based on data synchronization.
Those cases should both be solved with optimistic UI, so there’s no difference.
You can have a little checkmark to indicate that it’s synced, like many chat apps do.
> In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.
Yeah, can attest to this. I’m working on an app[1] that strikes the trifecta: p2p, real-time and offline first. All of those things combined makes the amount of tooling, design patterns and resources available shrink to a tiny sliver compared to a typical web-based tech stack. I have researched probably 100 projects that sound promising but almost all have been a poor fit for one reason or another. I opted to build almost everything from scratch.
Kudos to the JS ecosystem. They are way ahead in this space, with rxdb, watermelon, yjs, automerge etc. Unfortunately I couldn’t use any of them because I use a split-language stack.
rotate CRUD mindset to CQRS, now you have a start event and an end event, this is the extent of the pending sync state which can be afforded to the user at any granularity - document level, message level, form or field level, etc.
The cost is that other view queries don't reflect the pending event, only the view that issued the command has an association to the event. Which is usually the UX you want. Consider a master/detail form app where you insert a new record into a collection, but the view is sorted/filtered/paginated and your new record does not match the criteria and therefore vanishes. That is never the right UX. A less surprising alternative UX is to limit record creation to a specific form for the business rules of creation, and that form exists in the context of a specific collection view with business rules around newly created entities of that kind, with an invariant that newly created entities will always appear at the top or bottom of that collection (e.g. new messages are always added to the bottom of the chat history view). Now the optimistic update bypasses the database and simply writes through to the view optimistically and then when the ack is eventually received it seamlessly changes state without any UI jank.
Now you can send many new messages rapidly and if the nth message fails and the rest of the messages went through you get a properly located error. With a CRUD mindset, probably the form is simply disabled until each individual insert succeeds - which means your chat app cannot keep up with you typing!
When you need a single source of truth you cannot use optimistic UI.
E.g. if the user is a realtor, then she can't tell the customer "you have now bought the house" if there is no online connection and you're waiting for a sync. You can fill out and upload the form async, but commitment must be online.
You cannot tell the customer "you might have (or might not have) bought the house, we will only know later".
This is correct but you can do tricks to change who the counterparty is, which is often useful. If, instead of putting up a yard sign and saying "this house is for sale" and waiting for someone to come by and complete the transaction, the homeowners entered a contract with a brokerage to sell the house to anyone who is willing to abide by a list of terms (minimum price, occupancy date, etc.), then the brokerage can respond immediately and say "great, the house is yours". This is essentially the equivalent of sending a sell order to a stock broker.
In this case the optimistic UI might be good to have a step like “this request is pending”. So when the form is submitted the data is ready to send and will send when it can. Ideally with an indicator that the user is offline and needs to be online to sync.
That's true even if you're example isn't perfect. Some types of transactions have business requirements that demand immediate consistency or responses. Contraindications certainly don't invalidate ideas, though. Use the right to for the job.
First I heard of "optimistic UI" was with GraphQL and Apollo, but I had seen the behavior that they someone, perhaps them, gave this name for a lot before.
I don't find the concept "optimistic UI" to be more useful for talking about it or the implementation by Apollo to be more elegant. It's fine but it doesn't solve any problem except one that was created by Apollo's binding of server data to the client, React-style.
> Those cases should both be solved with optimistic UI, so there’s no difference.
Ah, yes, "in theory, the theory and the practice are the same". Unfortunately, in practice, the theory and the practice are not the same, and those cases are regularly not solved with optimistic UI (even though they should), so there is difference.
Git has one interface for disconnected commits and another one for connected ones. Most of the command set is bifurcated around this. Sure there are places where you do the same act for local and remote but those are more the exception than the rule. It's very exposed. They've done very little no create any sort of abstraction across them, and that's probably the right answer.
Ugh. This makes me very sad. Git is a ux disaster, and my gut instinct when realizing I was doing the same thing as git would be to seriously question my thought process.
I agree with the sentiment, but for entirely different reasons.
An offline capable application that sometimes tries to sync can be called "Online with Extreme Latency", but that is not what true ~~Scotsman~~ offline is.
Offline/online is first and foremost about data locality and data ownership. In an online application (regardless of latency!) the source of truth is "the server". Offline application itself is the source of truth and "the server" is a slave.
The OP seems to be talking about thin vs fat clients. Fat client is still a client - it fetches data. Offline application is the data source for "the server", it's the server that has to adapt to local changes not the other way around. Naturally, this is problematic since now you have multiple sources of truth. However, shifting source of truth to "the server" does create online application with extreme latency - fat client.
It doesn't matter if it's a proprietary format. Proprietary formats can be reverse engineered and modified and converted. There is a world of difference between a proprietary file that I have online in a form that I can't access directly (and I have no idea how it's being accessed, changed or stored by the service itself or third parties) and a file that I have on my harddrive that I have complete control over.
Yes, but I think most people care about availability of data over true ownership of data.
If I’m running a business and my internet goes out, there’s a huge selling point to a local DB that allows my operations to keep chugging along until Comcast figures out their mess. Internet returns, my DB syncs with a server offsite, and now I have that backup.
Isn't that more like "decentralized vs centralized" though? In my experience talking with coworkers about online vs offline apps, the article's definition is what we use. Granted, I've worked exclusively in Web dev for years so maybe it's all contextual.
I don't view things like the article states, and I likely won't for a number of reasons other commenters have stated, plus one more:
If offline is online with with extreme latency, then "extreme latency" must include "infinitely long latency". But accommodating infinitely long latency requires a different approach than if you assume that a server will be contacted at some point.
Yes and no, IMO. While these are different classifications, some concepts can be cross applied.
Decentralized essentially means absence of built-in omniscient entity - each end every connection is treated as one between equally correct peers. It does not mean that a pair of entities cannot establish hierarchy, it simply means they do not have to.
Take git for example. There is nothing forcing us to treat github/gitlab/etc as the omniscient node even if it is central point of data exchange - you are free to disagree with the upstream changes. Local data is always there, all local overwrites are explicit and so on. Contrast this with something like online game. The server will tell the client what their state is - there is a central entity controlling the truth.
Web can be interesting in this context, since there are multiple "tiers" of nodes: user applications, backend servers, databases. Data control and conflict resolution properties usually are different among nodes in the same tier and between tiers.
I think I agree with the analysis. It's why aspects like data verifiability are potentially more important than fancy peer-to-peer routing and transfer protocols. Once you have Merkle proofs of data, it's just as powerful whether it is on the client or server.
Trust and anti-corruption are just two of many properties you need for data locality, arguably less important. Conflict resolution or consensus is still very, very difficult. P2P routing and transfer is a bit of a red herring. You still need consensus between your local store and the remote store. Fireproof does it using IPFS underneath which in my experience tends to be quite slow, but is a working solution.
A good example of this is are mobile applications used in logistics for tracking movements within a terminal. Often the wifi environment is terrible and the operators will spend significant time not connected. They often have fat clients with local storage, and when the reconnect the sync bidirectionally - they upload whatever they have done since last connection, and they download changes others have made that may affect them in the meantime.
I believe thinking about it as "offline vs online" obscures what's actually difficult about offline operation. It's not storage or ownership of data that's difficult, it's conflict resolution.
The longer you're disconnected, the more things diverge, the better your merging/resolution schemes/algorithms need to be.
There are a lot of ways of thinking about and approaching the problem, some of which work worse or better under different circumstances. You see it in distributed consensus, multi-master systems, version control systems, etc.
There's ongoing work in the form of things like operational transforms and CRDTs, but clearly their needs to be a lot more progress in the area.
A lot of it is also about accessibility to someone with limited network access.
When you are developing with an always-on connection and a high-performing device, it's easy to ignore all the scenarios where someone doesn't have either one.
An app I was designing about six years back would have been something that some would use in their yard and others would use in a national park.
In the yard you have extreme latency. Sooner or later you'll get thirsty and you'll walk into WiFi distance.
In a national park there's no connectivity. You won't be able to get or receive anything until long after the moment has passed. None of the answers you get will be relevant anymore for most people (what percent of people who visit a national park visit the same one over and over again?).
Then I realized screen contrast wasn't 'there' yet so I shelved it, got busy, and there it remains collecting dust.
I've also worked on systems like that where a mobile user could loose connection at any time and they are indeed very complex to get right.
I'm not sure there's a perfect way to do it but we ended having have certain functions that had to be done online and others where the user built a "request" for service that was handled optimistically with failures sent to the user's inbox later.
The really hard part is conflict resolution. You updated something 5 times while offline, but another user deleted that something between updates 2 and 3, or made a divergent update of their own. There are so many potential scenarios like this in a multi-user app. It's a huge rabbit hole, and you can end up in situations where it's impossible to sync in a user-friendly way. Essentially you are taking on all the challenges of distributed databases. Maybe it's worth it, but you should know what you're getting into.
Online-only collaboration systems already have to do this. The local view has to synchronize state between other local views and the canonical version on the server. Offline changes are online edits with high latency.
> You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online.
I'm not sure you got the point. The design guideline that "Offline Is Just Online with Extreme Latency" already reflects very specific architectural requirements, and state transitions in the application life cycle. We're talking event-driven architectures, batching events, flushing events in offline/online transitions or even when minimizing windows, pulling events when going online, etc etc etc.
I'd go even further and claim that this whole "pessimistic vs optimistic UI" thing is just "adequate vs broken UI design",regardless whether the app is even expected to go online.
A related concern would be surfacing the "online" part as explicit resources and actions for the user instead of implicit, background magic. If you are sufficiently offline in your lifestyle, you need to plan your communication phases.
I recently got into using a GPS sports watch. It is the kind of thing I would want to use in an offline fashion, i.e. go somewhere off the grid and track my hikes or bike rides. These devices are designed to function offline for a stretch of time, but they have a requirement to eventually sync to an online system. They will eventually fill up with recorded sensor data and you want to offload that somewhere else before clearing local device storage. More importantly, satellite positioning receivers need a cached "ephemeris" file that helps them predict which satellites will be overhead at a given time to operate efficiently, accurately, and quickly.
Unfortunately, the manufacturers have been infected with smartwatch expectations. They started designing it as if it is always online, and the syncing functions are implicit background behaviors. When doing sporadic syncs and going back offline, it is hard to influence it to "get latest ephemeris" when you known you have internet connectivity and will be going offline again. Worse, these results are localized and it implicitly gets ephemeris for its current location. The UI doesn't allow you to indicate a destination and pre-load the right data to allow fully offline function on arrival.
> More importantly, satellite positioning receivers need a cached "ephemeris" file that helps them predict which satellites will be overhead at a given time to operate efficiently, accurately, and quickly.
Interesting, I've never heard of that particular optimization for GNSS before. I know GPS transmits ephemeris information in each frame, since that's the input data for the positioning calculations. I've got a number of Garmin watches, and they've always been able to get a position fix even after being disconnected for weeks.
I find GNSS implementations very interesting, which manufacturer is making their watches like this?
Garmin watches do! Go into the System -> About menu and there is a page showing ephemeris status.
Their documentation states that this may expire after approximately 30 days or if you travel more than 200 miles, while it will update during syncing.
I've seen it expire in less than two weeks with daily use of GPS but phone syncing disabled. It will still get position, but it can be the difference between an almost immediate fix after opening an activity menu or a delay for tens of seconds to minutes. Distance and pace measurements also seem to be lower quality when operating without a current ephemeris file.
Not exactly - there’s a bunch of non-trivial stuff you need to worry about when both local and remote states represent sources of truth. Things like CRDTs and event sourcing make it easier, but there’s still more complexity than dealing with only one source of truth.
In an online-first experience, any local state being held is (for the most part) an optimization or is intentionally ephemeral. You can just toss it away at a performance penalty if it ever gets too hairy.
In an offline-first experience, you need to be very careful that you treat everything like a source of truth. You also need to deal with schema migrations and business logic migrations, since you need those to partially live on the client.
Was required to use a MS sql server database for a project that would go offline for 5-10 minutes every hour. (Getting admins to fix it was a no go).
Now of course I was judged on uptime of my app that relied on it.
Finally just cloned the data to a local MySQL and refreshed data frequently. Database team totally clueless that app servers were hosting their own databases.
Whoa now. Don't go after the cash cow! It's so much harder to rent-seek when people just run regular programs that don't require 10 gigs of RAM and internet access. But where's the career promotion in that?
This one doesn't have much to do with online vs. offline except that you have to be online to see the "latest and greatest" ads. Stale ads can perfectly well be shown offline.
Traditionally they weren't on offline software though. It's an online-era thing, and it thrives on online-ness, both for getting the "new" ads and for sending impressions and telemetry back. Even on modern offline-software-with-ads it's usually a glorified web view.
They can, but an Android app I use regularly simply won't show any ads if it cannot access the internet - I get its premium version for free just by pressing a button. Meanwhile I've seen the user-hostile version of that on an iPad years ago, where an app simply locked itself until it was able to download ads.
This is a much bigger problem than people realize. Instead of working on improving user experience, we've got people explicitly working against user experience by injecting ads into it, for the simple reason that they have your attention and can then sell it. It's the attention economy, and it sucks. Fuck ads.
I think people are really only interested in commercial messages when they come at a much lower frequency than they do these days. Other than that, it’s just noise that we suffer through in order to get the information or content that we want.
>Other than that, it’s just noise that we suffer through in order to get the information or content that we want.
The trailing part that's left off is "for free". If you want all the content we receive for free today, someone has to pay for it. So either people pay with their attention or their wallet, and consumers have by and large made their choice of ad supported services over paid alternatives.
There's a great deal of technically unnecessary complexity that many people here handwave away because "that's just how it is."
It's kind of funny how, e.g. above, the emphasis is on "UI," when that's not it at all. It's the underlying infrastructure that's often encrusted layers of unnecessary (but profitable) stupid.
Anyone who thinks UI is where the latency and complexity resides should do a 3-mo residency at a cloud provider running actual infrastructure--not VMs and the like, but the actual routers, backbone links, service provider peering, and servers. It'll change your perspective on complexity for sure.
I know you can use ethernet to build a network but if you build a global network with 90s technology, you'll get what?... the internet like we know today but worse. What problem was solved?
That was my point responding to OP. We actually progressed and we are facing new challenges.
We're still using 90s technology. We only have faster switches, quicker routers, a couple of standards for faster connections, and some tools which disguise or repurpose deep packet inspection as "software defined networking".
A country wide router still can stay in service for a decade. Residential FTTx installations consist of a TelCo class switch, maybe a router, compact DSLAMs if you have DSL service and a couple of fibers in, tens of fibers out for FTTH customers.
It's faster hardware on the same stack. Nothing more, nothing less.
...and, oh, link-speed (transparent) DPI equipment in key places for lawful interception.
Theoretically, if an entire major city's connection with the outside world was cut off, could all the infrastructure within the city function as a really big city-wide LAN?
Yes. You might need a dhcpd on a laptop though, if your city's IP management is outside the said city (Cable/DSL modems needs their own IPs, unless they are static).
...and possibly a small DNS server (or a hosts file somewhere easy to get).
That's all you need.
If you want to navigate via IPs only, you can do with a DHCPd.
Depends on what you consider "work from home". You might not be able to chat with your co-workers without a WAN connection (unless you go really old-school and use a telephone), but you can for instance develop software from home without any working network connection (and git makes it easier by allowing you to create commits while offline; see also the "git bundle" subcommand). I've done so occasionally when the Internet connection goes kaputt.
In other news, old man yells at cloud. You conveniently ignore the changed reality: since the 90ies, the number of active internet users, malware, services, goods sold, and customer expectations have skyrocketed.
What you have in stock is nostalgia, my friend. Everything worked? Like Windows 95 crashing if you looked at it sideways, Linux requiring you to compile drivers for pretty much any device yourself, like fifteen competing printer protocols all incompatible with each other? You might want to get a reality check :)
so young man yells at old man yelling at cloud? TBF, software in the past handled fluctuating connectivity much much better than todays, probably because back then this was normal. Once you got a thing working (a printer driver, say) it typically worked.
Today, with spotty internet, software you have or could have on your device might or might not work. Just recently I have seen a website which loaded, but was non-functional until 2 mins later a cookie warning was also loaded.
Nothing in there is about
> the number of active internet users, malware, services, goods sold
but about not building for applications only loading half (because we are still waiting for some obscure JS or CSS from not the original domain that noone really never needs.)
At least the printer protocols have stayed true to themselves, the more the merrier.
Picking a random example: "AirPrint®, Brother iPrint&Scan, Mopria™ , Cortado Workplace, Wi-Fi Direct®".
Will a lists like that be enough to overcome your fear and skip the costly upsell to exactly the same printer, but it also understands PCL6? (likely a bit flipped in the firmware...) You decide. It's like a reverse confidence trick: "look, it's 2023 already and it's awesome, you really don't need PCL6 anymore. Trust me."
Haha I got a WiFi direct printer. It made no indication of working with Linux but it just worked out of the box. It came with a driver disk, and it's needed to get it working with windows ..
Nice to hear! I'm not really doing Linux on the desktop, but in this age of almost-but-not-quite paper free, I like to think of printers in decades. And on that time scale, "no special fiery hoops to jump through on Linux" is really the only thing that has any value as a predictor of future usefulness. After some googling my vague conclusion was that a full complement of wireless protocols would indeed be a tolerable substitute of PCL6, but I'm glad for the confirmation. (even if I recently dropped out of the printer market again, turns out that the day I gave up on my ca 2001 Samsung I just wasn't sufficiently desperate to tease it into accepting an empty page as something to print on)
"paper free" sounds un-fun. I have a brother laser, that replaced a 2 decade old HP laser that my youngest broke when he was 2 or 3. We go through about 3 reams a year, more when one of us is going for a degree. I print maybe 5 things a month on average, usually recipes. I wouldn't forego a printer for any reason.
you can use gimp to take images and make them into coloring book pages, you can print instructions, calendars, drawings, diagrams; prompts for writing, your own writing to make sure that the "screen" isn't tricking your brain making you miss editing/grammar errors. Coloring pages, maps of countries, and other educational things are more fun if you can hold them and put them on your wall, if my kids are any indication. Having a scanner and a copier and a networked printer in a single box for what they cost - that makes it difficult to see the aversion.
I have had fancy e-readers since the original kindle, and before that a Clie and two palm pilots with acrobat and an epub (or whatever) reader. and i still prefer dead wood. I read more books on paper than e-ink. I read more on a computer screen than books, though.
In the late 90s, I used to collaborate with about 10 people, all in the same office on the same LAN, for production of a magazine that sold IT stuff.
We used the "Excel Shared Spreadsheet" functionality. The file was hosted on a network drive. It corrupted or crashed so frequently - even when only one person had it open - that we took to copying it to your local machine, making the network copy read-only, editing the local copy, then copying back onto the network drive. Even this was buggy, so possession of a stuffed octopus represented a lock on the file. Microsoft themselves got involved at one point, as we were a reseller for their products. Their solution was no better.
So if there was a halcyon period for collaboration at some point in the past, I'd like to know when it was. When I see 100 people live editing the same Google Sheet, I think perhaps we are in the golden age.
Heh, we had a similar process for modifying the schema for an Access database or… something adjacent to it. There was a bunch of XML that needed to be versioned and if two people modified it, committed to SVN, and merged, there was almost certainly going to be huge breakage. I went out for a cigarette after one of the moments of frustration, saw a nice maybe 2kg rock, and the Lock Rock was born :D
> You conveniently ignore the changed reality: since the 90ies, the number of active internet users, malware, services, goods sold, and customer expectations have skyrocketed.
Now our printers, cars, and soon fridges are DRM-locked and doing surveillance.
And they can stop working at any time if the manufacturer goes bankrupt or simply stop supporting them.
in the 90s, there was microsoft messenger. real time, point to point (and maybe ptmp) chat, audio, and video. What replaced it? I have to run a coturn (STUN) server just to be able to talk to my friend in a private way, which means now i gotta deal with some provider for hosting both coturn and, say, Matrix (Synapse).
I also run a PBX, just in case coturn decides to stop working from lack of use. Now i gotta make sure i start the PBX app (3cx) once a week otherwise android helpfully removes notifications for me!
AIM, ICQ, etc were great - and i'm discounting "presence", because that was a small part of it. realtime communication for "free". I've been running chat servers for over a decade, and right now, there's three people on my matrix server, me, wife, and my best friend. there's five people on my PBX, same three plus my youngest child without a SIM card, and grandma, so grandma can call kid and vice versa. I've run ircd, matrix, rocket.chat, mattermost, a couple of the jabber systems, ventrilo, teamspeak, hand-rolled garbage.
we've had people sign up and chat once, but as soon as notifications stop working we never see them again. Heck, i have 3 PUSH accounts just to make sure that notifications go through everywhere.
Meanwhile, 20-25 years ago, load up trillian or AIM/ICQ and there was everyone, literally everyone. I know facebook ate that lunch, but i refuse to have any facebook apps on my phone, and most people i know refuse as well, so that's a non-starter. Texting is still spotty, because VoWiFi tends to just magically stop working if you leave the wifi area a couple times in a day, so texts will sit in limbo until you realize. Phone calls are the same way (except via PBX, those always seem to work for some reason...)
running out of IPv4 and the ubiquitousness of CGNAT have killed what the internet was. And that's sad; "nostalgia" isn't necessarily a negative thing. It used to be better, at least in the West. Maybe wechat and signal and telegram and whatever work better for the rest of the world now than any of our stuff from 25 years ago, i wouldn't know, because i know exactly zero people on any of those services - i've checked, once every couple of years.
But have you tried to move any users over to, "wechat and signal and telegram and whatever"? Getting users onto your own system wasn't trivial. If you want to move to a more supported system like, say, Signal, then you have to pay the platform switching costs, which includes moving your group of people. Which involves having the social capital to do so, which is unfortunate for the less social of us.
There are many things that killed what the Internet was in the 20-30 years hence. IPv4 exhaustion is regrettable, but entirely predicted, and for those in the west, not a huge deal. I can pay any number of cloud providers a small fee to host me a box with a publicly routable IPv4 address. CGNAT is annoying, but the number of libraries which will punch a hole in that NAT has also expanded by a huge margin since the 90's. So those up things are unfortunate, but I think there are many other things that changed the Internet, some for the better, some for the worse.
> But have you tried to move any users over to, "wechat and signal and telegram and whatever"?
no, because everyone uses something different and there's no "trillian" or meebo for all the shiny-tech. If we're going to play "encrypted chat", that no one can agree what that means, or what service to use, may as well use my own. Hopefully matrix becomes more popular (it probably won't, unfortunately*), but if not, i still won't use the likes of telegram or FB messenger or tiktok DMs or anything of that nature. there's not a good IRC client for phones, last few times i checked over the past 15 years.
* Matrix has the curse of being good enough on the client side, but kind of a PITA on the server side. Synapse, the reference implementation is in python, which is single threaded, so joining a large room "as-is" out-of-the-box is not feasible. You have to split each of the synapse elements into a microservice that gets its own python instance, but the documentation was (and probably still is) quite sparse. I'm sure there's a discord where i can get help.
Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time.
I've considered Git but not sure how much overhead it adds.
> Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time. I've considered Git [...]
If you've considered git, I would suggest looking at git-annex (https://git-annex.branchable.com/), which is tuned for that kind of mostly-offline use case.
Effectively sync systems like DropBox and iCloud do this by flagging conflicting edits when you come back online and duplicate files (new a new file name) so there is no data loss.
For a lower level file system though that's not really possible as you may be running databases, or other data models, that need to understand conflict resolution themselves.
why would you share a database over a distributed filesystem, other than for backup purposes where you only have a single source so you should never get a conflict?
For my personal use case I don't really care about conflicts - they could be crudely resolved by a timestamp or even randomly. Having backups in the event of a conflict would be good. Files are never updated incrementally, just added, renamed or deleted.
That's intractable. Conflict resolution has to be done differently for different types of data, so it has to be done at a higher level than filesystem, unless you want a special filesystem that only supports a specific kind of file or has some other very significant restrictions.
He is not talking about offline applications but online applications with offline functionality.
Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input.
And I'm not a fast typist.
> Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.
If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response, it's doing something horribly wrong and if that's how they write things, you probably want to avoid that for a multitude of reasons. Please name and shame though, so others can avoid it too :)
Same goes for Electron-based applications, there is no reason they'd block showing the text you inputted, and if they just use <input/> without doing anything egregious, you really shouldn't be able to type faster than characters appearing on the screen, something is really, really wrong then, and I don't think it's because of Electron.
1Password’s new UI does just that.
I enter some text into a field quickly, hit Tab, then watch some of the trailing characters (or the entire field content) disappear.
This keeps occurring and disgusting me to no end.
> If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response
I'm 99% sure nobody does that, that would be insane :D.
It's most likely caused by React and the use of controlled input components without thinking about performance. If your input sets it's value from React state, then you're updating the state on every keypress and re-rendering the component. In the most simple case, it's probably fine. But depending on your component hierarchy, it's pretty easy to end up in situation with over 50ms of typing latency.
> I'm 99% sure nobody does that, that would be insane :D.
I agree, hence the surprise!
Although parent explicitly calls out "cloud applications" so I'm guessing online has something to do with it.
And in the context of online/offline, it wouldn't matter if it's internet connected or not, using controlled input components with state changes going through a deep hierarchy would introduce that sort of delay no matter if you're online or offline.
I issues with Outlook Web App (M365) often. Dropped characters are not so common, but it is common for the cursor to bug out and insist on returning the to start of a line with each new character.
Are you using Firefox? I had that problem consistently with OWA, but I recently switched to primarily Safari on an old MacBook and don’t recall having it happen recently.
Gmail has had this issue for years, if you type in the search bar a bit fast or the system is a bit busy, some of your key presses will trigger keyboard shortcuts and randomly select/archive/mark as read/open emails in the current view. This is maddening because you can end up missing emails completely as there is only a single level of undo.
VS Code is still much slower than necessary despite editing files locally - on my Thinkpad from 2016 I got extremely inconsistent input latency that felt like a shaky SSH session, in better cases it seems to be closer to 30ms[0]. For reference: gVim's latency hovers around 1ms and even intelliJ can still be 10x faster[1].
It's more if I edit data grids or multiple fields where I switch between them with the tab key.
On desktop applications they may lack in the response on the screen if they or the computer are to slow, but with cloud apps sometimes keystrokes go missing and the entered data is in the wrong field.
The operating system recognises all keystrokes, but the browser seems to skip some.
This is increasingly happening with desktop apps as they get rewritten to be async throughout without a good understanding of what this implies. The old single-threaded UI model with a message pump was hard on the developer (if they wanted to keep the UI response) by requiring them to manage all asynchrony explicitly with threads, but at the same time it also forced to think things through more. Now it's often just throwing async/await or equivalent around mindlessly, and it leads to the same exact kind of bugs you describe.
I think that’s the take and from my own experience, it kind of sucks and feels like we’re running worst versions of basic software than we used to (old man rant?).
For example, I use Apple Music every time I leave my apartment. Put my headphones on and start some music. All my songs are downloaded locally so it should be fine, however, as soon as I close my front door until after I step off the elevator, no music will even attempt to play. That’s because Apple Music is blocking itself on some sort of network call/drm check because it thinks I’m online and it should work.
If I go into airplane mode and hit play, everything works perfectly.
Yeah and riding 1000cc bike is just like driving the bicycle with Extreme Speed /s
> In the case of webRTC, I've seen so many projects do this where they’re like, “It‘s peer-to-peer! You just connect to the signaling server and then the things talks!” That’s not really peer-to-peer cause you've got a server. If you've already got a server...my advice is: don't mess around with peer-to-peer stuff, just use that server.
The prevalence of NAT really did a number on ability to have properly p2p communication. And, well, rampant insecurity of default user setups making most internet connection be at the very least behind "only allow outgoing traffic or traffic initiated by user" type of firewall.
Even if you make all that nice code with each user having it nice and secure private key and having to accept someone's public key to start communicating there is still problem with distribution and ascertaining that user is really who they are.
And even if they are, well, they can be compromised, so your local app also have to be very secure or else the potential malware can just go between your contacts and compromise everyone using the app.
Or, you can just use SaaS and don't worry about it, or at the very least not worry about more than one app having ability to compromise your system
NAT is definitely the villain but their are other things as well. You still need a discovery system to find who you want to connect with. An ip isn’t very good because it moves around, and DNS is too slow to be operationally viable.
And even if you solve those you have an N^2 problem in the naive solution, and to reduce that you need mesh networks which just don’t have the QoS we’ve come to expect (to my meager knowledge).
Imo we should be able to find a better middle ground, because full decentralization is insanely hard. If we had federated standards and tooling like web and email, but for modern use cases, I’d be a happy man.
Despite (or perhaps because) the tech craze over the last decade, the developments of such open and useful standards leaves a lot to be desired. Almost everything cool these days is some app with perhaps an api that is branded as a “platform”. We’re basically treading water.
It's a bit like when smart phones happed we started doing ui "mobile first" as it easer to scale up a mobile UI to desktop, it's easier to start "offline first" and move to constantly online (even collaborative) than to start online first and add "offline" eventual consistency later.
There is much chat about real-time collaborative apps, but the reality is that most people are working async most of the time. If you start with the concept of offline first, with eventual consistency for collaborative work, you implement all of the same conflict resolution as if you are implementing a real-time app with conflict resolution. Then adding real-time collaboration later is easy.
This is where CRDTs (conflict free replicated datatypes) work better than OT (operational transforms). OT need more supervision from the server, the further you diverge from the servers state the more likely there will be a corruption. CRDTs are inherently designed to work with massive diversion and no central authority, really they are offline first.
Just retry each X seconds. Also browsers have a navigator.onLine property which emits an event at the exact time the client is online again. I am doing this with rxdb and it works great.
With apps I do this. I download the entire rest api. Often 5-10 mb.Entire api is versioned, every content update leads to new live version. And app works offline and super fast. Queue the api updates by default. And cache images / videos. Pretty doable. And api is rarely queried.
There is _one_ thing that can allow "two machines in the same room to talk to each other without sending a request to a server farm in Virginia". It does require the _first_ request to populate the app: Web Bluetooth. Unfortunately it's only implemented in Chrome,but it does work.
P2P in browser was improved a lot in the past years. Your two machines could now connect via WebRTC and then send data to each other directly, no need for bluetooth. This works great and has a low latency. With rxdb you could even realtime-sync the whole application state [1] without connection to a server farm in virginia.
an email client is a good example: you can read and send emails also offline (at least with most clients that keep a decent cache) and only synchronise when connected. But that works for some services, not all.
Does your laptop have 200 terabytes of memory, 50 petabytes of storage, and 10,000 CPUs? No? Then it's not really the same thing is it?
There are things you can never do on your laptop. Offline is limiting, in many ways. You know how I know? I grew up in the 90s. Online is a magical godsend of capability and functionality. Offline is cute. Online is what we dreamed of.
Should you have offline modes? Of course. Should you have some offline-first applications? Of course. Is offline just online with extreme latency? Of course it isn't. Use your brain. Think.
IF you can solve data sync for your application, local first is simple & easy to develop and feels very responsive for users. Lots of business applications are now in that range. 10MB of ERP data is like 1 year of operating a medium sized company is the equivalent of a picture of my cat.
TL;DR: This is about offline communications and not the world in general. It also assumes that communication is achievable. In the real world (offline and online), we have problems with that. When you attempt to communicate online you are often redirected "through the gift shop" so you can be shown the exact number of ads such that you statistically won't give up and pick up the phone (and I'm sure phonecalls will have pre-roll ads at some point too).
In fact, ad-hoc random person-to-person communications online are gatekept by "the algorithm" which would rather answer your question directly to keep you from meeting another warm body online.
LTO-9 tapes do 45TB compressed, 18TB uncompressed. And uses around 0.23 cubic decimeter of storage.
A European station wagon with the rear seats folded takes 1555 liters, with 95% utility that is 6422 tapes. That wagon can hold 289 Petabyte of compressed data
From Amsterdam to Rotterdam, it takes about an hour to get your data to its destination. That is roughly 640 Terabits per second. For comparison, AMS-IX peaked at 11 Terabits per second last year.
A fair comparison with AMS-IX would perhaps need to factor in the time spent reading/writing the tapes though. Compressed LTO-9 tapes can be fully read in about 12.5 hours, so assuming for sake of argument that your car contains 6422 compressed tapes with a total of 289PB of data on them already, and that you have (a rather expensive) array of 26 LTO-9 drives at your disposal in Rotterdam, you'll need about 130 days to fully read their data. The hour of driving across Holland is rather insignificant compared to that. All in all, you get 'only' 26 GB per second, limited to that only by having 26 drives.
249 comments
[ 5.1 ms ] story [ 269 ms ] threadoffline means no expectation of a response, that is very different than an extremely delayed response
If it works locally and there's no need for syncing or communication in the first place then yeah, problem solved!
For example, say you have a form. If you built it thinking online first you'll probably have some pessimistic UI which shows a spinner and waits for the server to respond with ok/error. You can't simply think, okay since we're offline, more latency -> show spinner for longer. You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online.
In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.
Isn't that exactly what the article argues for though?
> This kind of idea would move you away from a product full of API calls to one based on data synchronization.
You can have a little checkmark to indicate that it’s synced, like many chat apps do.
> In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.
Yeah, can attest to this. I’m working on an app[1] that strikes the trifecta: p2p, real-time and offline first. All of those things combined makes the amount of tooling, design patterns and resources available shrink to a tiny sliver compared to a typical web-based tech stack. I have researched probably 100 projects that sound promising but almost all have been a poor fit for one reason or another. I opted to build almost everything from scratch.
Kudos to the JS ecosystem. They are way ahead in this space, with rxdb, watermelon, yjs, automerge etc. Unfortunately I couldn’t use any of them because I use a split-language stack.
[1]: https://payload.app/
rotate CRUD mindset to CQRS, now you have a start event and an end event, this is the extent of the pending sync state which can be afforded to the user at any granularity - document level, message level, form or field level, etc.
The cost is that other view queries don't reflect the pending event, only the view that issued the command has an association to the event. Which is usually the UX you want. Consider a master/detail form app where you insert a new record into a collection, but the view is sorted/filtered/paginated and your new record does not match the criteria and therefore vanishes. That is never the right UX. A less surprising alternative UX is to limit record creation to a specific form for the business rules of creation, and that form exists in the context of a specific collection view with business rules around newly created entities of that kind, with an invariant that newly created entities will always appear at the top or bottom of that collection (e.g. new messages are always added to the bottom of the chat history view). Now the optimistic update bypasses the database and simply writes through to the view optimistically and then when the ack is eventually received it seamlessly changes state without any UI jank.
Now you can send many new messages rapidly and if the nth message fails and the rest of the messages went through you get a properly located error. With a CRUD mindset, probably the form is simply disabled until each individual insert succeeds - which means your chat app cannot keep up with you typing!
E.g. if the user is a realtor, then she can't tell the customer "you have now bought the house" if there is no online connection and you're waiting for a sync. You can fill out and upload the form async, but commitment must be online.
You cannot tell the customer "you might have (or might not have) bought the house, we will only know later".
Sure you can - in fact, that's what realtors call offers. You place an offer, and you only find out later if you bought the house, often days later.
Eventually you do need to be able to commit some sort of transaction and get confirmation from the counterparty.
I don't find the concept "optimistic UI" to be more useful for talking about it or the implementation by Apollo to be more elegant. It's fine but it doesn't solve any problem except one that was created by Apollo's binding of server data to the client, React-style.
Ah, yes, "in theory, the theory and the practice are the same". Unfortunately, in practice, the theory and the practice are not the same, and those cases are regularly not solved with optimistic UI (even though they should), so there is difference.
An offline capable application that sometimes tries to sync can be called "Online with Extreme Latency", but that is not what true ~~Scotsman~~ offline is.
Offline/online is first and foremost about data locality and data ownership. In an online application (regardless of latency!) the source of truth is "the server". Offline application itself is the source of truth and "the server" is a slave.
The OP seems to be talking about thin vs fat clients. Fat client is still a client - it fetches data. Offline application is the data source for "the server", it's the server that has to adapt to local changes not the other way around. Naturally, this is problematic since now you have multiple sources of truth. However, shifting source of truth to "the server" does create online application with extreme latency - fat client.
not necessarily if the data is stored in a proprietary format.
If I’m running a business and my internet goes out, there’s a huge selling point to a local DB that allows my operations to keep chugging along until Comcast figures out their mess. Internet returns, my DB syncs with a server offsite, and now I have that backup.
If offline is online with with extreme latency, then "extreme latency" must include "infinitely long latency". But accommodating infinitely long latency requires a different approach than if you assume that a server will be contacted at some point.
Decentralized essentially means absence of built-in omniscient entity - each end every connection is treated as one between equally correct peers. It does not mean that a pair of entities cannot establish hierarchy, it simply means they do not have to.
Take git for example. There is nothing forcing us to treat github/gitlab/etc as the omniscient node even if it is central point of data exchange - you are free to disagree with the upstream changes. Local data is always there, all local overwrites are explicit and so on. Contrast this with something like online game. The server will tell the client what their state is - there is a central entity controlling the truth.
Web can be interesting in this context, since there are multiple "tiers" of nodes: user applications, backend servers, databases. Data control and conflict resolution properties usually are different among nodes in the same tier and between tiers.
Cryptographic verifiability make data locality into an optimization problem not a trust problem: https://fireproof.storage/documentation/how-the-database-eng...
The longer you're disconnected, the more things diverge, the better your merging/resolution schemes/algorithms need to be.
There are a lot of ways of thinking about and approaching the problem, some of which work worse or better under different circumstances. You see it in distributed consensus, multi-master systems, version control systems, etc.
There's ongoing work in the form of things like operational transforms and CRDTs, but clearly their needs to be a lot more progress in the area.
When you are developing with an always-on connection and a high-performing device, it's easy to ignore all the scenarios where someone doesn't have either one.
But I think it’s part of webTooling in the browser
In the yard you have extreme latency. Sooner or later you'll get thirsty and you'll walk into WiFi distance.
In a national park there's no connectivity. You won't be able to get or receive anything until long after the moment has passed. None of the answers you get will be relevant anymore for most people (what percent of people who visit a national park visit the same one over and over again?).
Then I realized screen contrast wasn't 'there' yet so I shelved it, got busy, and there it remains collecting dust.
I've also worked on systems like that where a mobile user could loose connection at any time and they are indeed very complex to get right.
I'm not sure there's a perfect way to do it but we ended having have certain functions that had to be done online and others where the user built a "request" for service that was handled optimistically with failures sent to the user's inbox later.
I'm not sure you got the point. The design guideline that "Offline Is Just Online with Extreme Latency" already reflects very specific architectural requirements, and state transitions in the application life cycle. We're talking event-driven architectures, batching events, flushing events in offline/online transitions or even when minimizing windows, pulling events when going online, etc etc etc.
I'd go even further and claim that this whole "pessimistic vs optimistic UI" thing is just "adequate vs broken UI design",regardless whether the app is even expected to go online.
I recently got into using a GPS sports watch. It is the kind of thing I would want to use in an offline fashion, i.e. go somewhere off the grid and track my hikes or bike rides. These devices are designed to function offline for a stretch of time, but they have a requirement to eventually sync to an online system. They will eventually fill up with recorded sensor data and you want to offload that somewhere else before clearing local device storage. More importantly, satellite positioning receivers need a cached "ephemeris" file that helps them predict which satellites will be overhead at a given time to operate efficiently, accurately, and quickly.
Unfortunately, the manufacturers have been infected with smartwatch expectations. They started designing it as if it is always online, and the syncing functions are implicit background behaviors. When doing sporadic syncs and going back offline, it is hard to influence it to "get latest ephemeris" when you known you have internet connectivity and will be going offline again. Worse, these results are localized and it implicitly gets ephemeris for its current location. The UI doesn't allow you to indicate a destination and pre-load the right data to allow fully offline function on arrival.
Interesting, I've never heard of that particular optimization for GNSS before. I know GPS transmits ephemeris information in each frame, since that's the input data for the positioning calculations. I've got a number of Garmin watches, and they've always been able to get a position fix even after being disconnected for weeks.
I find GNSS implementations very interesting, which manufacturer is making their watches like this?
Their documentation states that this may expire after approximately 30 days or if you travel more than 200 miles, while it will update during syncing.
I've seen it expire in less than two weeks with daily use of GPS but phone syncing disabled. It will still get position, but it can be the difference between an almost immediate fix after opening an activity menu or a delay for tens of seconds to minutes. Distance and pace measurements also seem to be lower quality when operating without a current ephemeris file.
I think that optimistic UI isn't more complex to build: it's just less familiar.
In a broader sense, UI/UX design culture places way too much focus and value on familiarity.
The best UI/UX designs I have ever experienced are when software design diverges from the norm and tries a new approach.
Having multiple records of state that have to be resolved when systems come online is complex. Anything requiring consensus is difficult to do.
In an offline-first experience, you need to be very careful that you treat everything like a source of truth. You also need to deal with schema migrations and business logic migrations, since you need those to partially live on the client.
Now of course I was judged on uptime of my app that relied on it.
Finally just cloned the data to a local MySQL and refreshed data frequently. Database team totally clueless that app servers were hosting their own databases.
extreme latency for any new data fetch/processing (an http roundtrip or more for each interaction with your data)
someone else being in control of the programs you use, forcing changes and updates whenever they like, renting them as a service,
your data hostage, snooped at, sold to advertisers
a limited UI experience based on the DOM and browser APIs
crappy OS integration
(often) ads
This one doesn't have much to do with online vs. offline except that you have to be online to see the "latest and greatest" ads. Stale ads can perfectly well be shown offline.
They can, but an Android app I use regularly simply won't show any ads if it cannot access the internet - I get its premium version for free just by pressing a button. Meanwhile I've seen the user-hostile version of that on an iPad years ago, where an app simply locked itself until it was able to download ads.
This is a much bigger problem than people realize. Instead of working on improving user experience, we've got people explicitly working against user experience by injecting ads into it, for the simple reason that they have your attention and can then sell it. It's the attention economy, and it sucks. Fuck ads.
The trailing part that's left off is "for free". If you want all the content we receive for free today, someone has to pay for it. So either people pay with their attention or their wallet, and consumers have by and large made their choice of ad supported services over paid alternatives.
There's a great deal of technically unnecessary complexity that many people here handwave away because "that's just how it is."
It's kind of funny how, e.g. above, the emphasis is on "UI," when that's not it at all. It's the underlying infrastructure that's often encrusted layers of unnecessary (but profitable) stupid.
Anyone who thinks UI is where the latency and complexity resides should do a 3-mo residency at a cloud provider running actual infrastructure--not VMs and the like, but the actual routers, backbone links, service provider peering, and servers. It'll change your perspective on complexity for sure.
Now, you need 5Mbit speeds just to collaborate. Funny how the tech "progressed".
DSL & Cable encapsulates Ethernet. City-wide networks are again Ethernet. In fact, everything is Ethernet with some routers between.
So, you're actually using a mixed-carrier Enthernet LAN with a couple of NATs in the way. You can build another LAN on your LAN with VPN, too.
That was my point responding to OP. We actually progressed and we are facing new challenges.
A country wide router still can stay in service for a decade. Residential FTTx installations consist of a TelCo class switch, maybe a router, compact DSLAMs if you have DSL service and a couple of fibers in, tens of fibers out for FTTH customers.
It's faster hardware on the same stack. Nothing more, nothing less.
...and, oh, link-speed (transparent) DPI equipment in key places for lawful interception.
...and possibly a small DNS server (or a hosts file somewhere easy to get).
That's all you need.
If you want to navigate via IPs only, you can do with a DHCPd.
Depends on what you consider "work from home". You might not be able to chat with your co-workers without a WAN connection (unless you go really old-school and use a telephone), but you can for instance develop software from home without any working network connection (and git makes it easier by allowing you to create commits while offline; see also the "git bundle" subcommand). I've done so occasionally when the Internet connection goes kaputt.
What you have in stock is nostalgia, my friend. Everything worked? Like Windows 95 crashing if you looked at it sideways, Linux requiring you to compile drivers for pretty much any device yourself, like fifteen competing printer protocols all incompatible with each other? You might want to get a reality check :)
It's not much better on modern Fedora. The drivers do come precompiled but you have to reboot sometimes twice per week to install updates.
Today, with spotty internet, software you have or could have on your device might or might not work. Just recently I have seen a website which loaded, but was non-functional until 2 mins later a cookie warning was also loaded.
Nothing in there is about
> the number of active internet users, malware, services, goods sold
but about not building for applications only loading half (because we are still waiting for some obscure JS or CSS from not the original domain that noone really never needs.)
Picking a random example: "AirPrint®, Brother iPrint&Scan, Mopria™ , Cortado Workplace, Wi-Fi Direct®".
Will a lists like that be enough to overcome your fear and skip the costly upsell to exactly the same printer, but it also understands PCL6? (likely a bit flipped in the firmware...) You decide. It's like a reverse confidence trick: "look, it's 2023 already and it's awesome, you really don't need PCL6 anymore. Trust me."
you can use gimp to take images and make them into coloring book pages, you can print instructions, calendars, drawings, diagrams; prompts for writing, your own writing to make sure that the "screen" isn't tricking your brain making you miss editing/grammar errors. Coloring pages, maps of countries, and other educational things are more fun if you can hold them and put them on your wall, if my kids are any indication. Having a scanner and a copier and a networked printer in a single box for what they cost - that makes it difficult to see the aversion.
I have had fancy e-readers since the original kindle, and before that a Clie and two palm pilots with acrobat and an epub (or whatever) reader. and i still prefer dead wood. I read more books on paper than e-ink. I read more on a computer screen than books, though.
We used the "Excel Shared Spreadsheet" functionality. The file was hosted on a network drive. It corrupted or crashed so frequently - even when only one person had it open - that we took to copying it to your local machine, making the network copy read-only, editing the local copy, then copying back onto the network drive. Even this was buggy, so possession of a stuffed octopus represented a lock on the file. Microsoft themselves got involved at one point, as we were a reseller for their products. Their solution was no better.
So if there was a halcyon period for collaboration at some point in the past, I'd like to know when it was. When I see 100 people live editing the same Google Sheet, I think perhaps we are in the golden age.
Now our printers, cars, and soon fridges are DRM-locked and doing surveillance.
And they can stop working at any time if the manufacturer goes bankrupt or simply stop supporting them.
I also run a PBX, just in case coturn decides to stop working from lack of use. Now i gotta make sure i start the PBX app (3cx) once a week otherwise android helpfully removes notifications for me!
AIM, ICQ, etc were great - and i'm discounting "presence", because that was a small part of it. realtime communication for "free". I've been running chat servers for over a decade, and right now, there's three people on my matrix server, me, wife, and my best friend. there's five people on my PBX, same three plus my youngest child without a SIM card, and grandma, so grandma can call kid and vice versa. I've run ircd, matrix, rocket.chat, mattermost, a couple of the jabber systems, ventrilo, teamspeak, hand-rolled garbage.
we've had people sign up and chat once, but as soon as notifications stop working we never see them again. Heck, i have 3 PUSH accounts just to make sure that notifications go through everywhere.
Meanwhile, 20-25 years ago, load up trillian or AIM/ICQ and there was everyone, literally everyone. I know facebook ate that lunch, but i refuse to have any facebook apps on my phone, and most people i know refuse as well, so that's a non-starter. Texting is still spotty, because VoWiFi tends to just magically stop working if you leave the wifi area a couple times in a day, so texts will sit in limbo until you realize. Phone calls are the same way (except via PBX, those always seem to work for some reason...)
running out of IPv4 and the ubiquitousness of CGNAT have killed what the internet was. And that's sad; "nostalgia" isn't necessarily a negative thing. It used to be better, at least in the West. Maybe wechat and signal and telegram and whatever work better for the rest of the world now than any of our stuff from 25 years ago, i wouldn't know, because i know exactly zero people on any of those services - i've checked, once every couple of years.
There are many things that killed what the Internet was in the 20-30 years hence. IPv4 exhaustion is regrettable, but entirely predicted, and for those in the west, not a huge deal. I can pay any number of cloud providers a small fee to host me a box with a publicly routable IPv4 address. CGNAT is annoying, but the number of libraries which will punch a hole in that NAT has also expanded by a huge margin since the 90's. So those up things are unfortunate, but I think there are many other things that changed the Internet, some for the better, some for the worse.
no, because everyone uses something different and there's no "trillian" or meebo for all the shiny-tech. If we're going to play "encrypted chat", that no one can agree what that means, or what service to use, may as well use my own. Hopefully matrix becomes more popular (it probably won't, unfortunately*), but if not, i still won't use the likes of telegram or FB messenger or tiktok DMs or anything of that nature. there's not a good IRC client for phones, last few times i checked over the past 15 years.
* Matrix has the curse of being good enough on the client side, but kind of a PITA on the server side. Synapse, the reference implementation is in python, which is single threaded, so joining a large room "as-is" out-of-the-box is not feasible. You have to split each of the synapse elements into a microservice that gets its own python instance, but the documentation was (and probably still is) quite sparse. I'm sure there's a discord where i can get help.
I've considered Git but not sure how much overhead it adds.
If you've considered git, I would suggest looking at git-annex (https://git-annex.branchable.com/), which is tuned for that kind of mostly-offline use case.
Effectively sync systems like DropBox and iCloud do this by flagging conflicting edits when you come back online and duplicate files (new a new file name) so there is no data loss.
For a lower level file system though that's not really possible as you may be running databases, or other data models, that need to understand conflict resolution themselves.
Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.
If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response, it's doing something horribly wrong and if that's how they write things, you probably want to avoid that for a multitude of reasons. Please name and shame though, so others can avoid it too :)
Same goes for Electron-based applications, there is no reason they'd block showing the text you inputted, and if they just use <input/> without doing anything egregious, you really shouldn't be able to type faster than characters appearing on the screen, something is really, really wrong then, and I don't think it's because of Electron.
I'm 99% sure nobody does that, that would be insane :D.
It's most likely caused by React and the use of controlled input components without thinking about performance. If your input sets it's value from React state, then you're updating the state on every keypress and re-rendering the component. In the most simple case, it's probably fine. But depending on your component hierarchy, it's pretty easy to end up in situation with over 50ms of typing latency.
I agree, hence the surprise!
Although parent explicitly calls out "cloud applications" so I'm guessing online has something to do with it.
And in the context of online/offline, it wouldn't matter if it's internet connected or not, using controlled input components with state changes going through a deep hierarchy would introduce that sort of delay no matter if you're online or offline.
I imagine you haven't seen how people implement autocomplete on web forms ;).
MS Teams does this when starting a new chat - you select the recipient and start typing and Teams will do two unexpected things shortly afterwards:
[0] https://github.com/microsoft/vscode/issues/161622#issuecomme...
[1] https://pavelfatin.com/typing-with-pleasure/#windows
On desktop applications they may lack in the response on the screen if they or the computer are to slow, but with cloud apps sometimes keystrokes go missing and the entered data is in the wrong field.
The operating system recognises all keystrokes, but the browser seems to skip some.
https://news.ycombinator.com/item?id=13940014
In the nitty gritty they are the same thing, but the way you say it changes the way you picture it and what parts you make sync vs async
For example, I use Apple Music every time I leave my apartment. Put my headphones on and start some music. All my songs are downloaded locally so it should be fine, however, as soon as I close my front door until after I step off the elevator, no music will even attempt to play. That’s because Apple Music is blocking itself on some sort of network call/drm check because it thinks I’m online and it should work.
If I go into airplane mode and hit play, everything works perfectly.
> In the case of webRTC, I've seen so many projects do this where they’re like, “It‘s peer-to-peer! You just connect to the signaling server and then the things talks!” That’s not really peer-to-peer cause you've got a server. If you've already got a server...my advice is: don't mess around with peer-to-peer stuff, just use that server.
The prevalence of NAT really did a number on ability to have properly p2p communication. And, well, rampant insecurity of default user setups making most internet connection be at the very least behind "only allow outgoing traffic or traffic initiated by user" type of firewall.
Even if you make all that nice code with each user having it nice and secure private key and having to accept someone's public key to start communicating there is still problem with distribution and ascertaining that user is really who they are.
And even if they are, well, they can be compromised, so your local app also have to be very secure or else the potential malware can just go between your contacts and compromise everyone using the app.
Or, you can just use SaaS and don't worry about it, or at the very least not worry about more than one app having ability to compromise your system
And even if you solve those you have an N^2 problem in the naive solution, and to reduce that you need mesh networks which just don’t have the QoS we’ve come to expect (to my meager knowledge).
Imo we should be able to find a better middle ground, because full decentralization is insanely hard. If we had federated standards and tooling like web and email, but for modern use cases, I’d be a happy man.
Despite (or perhaps because) the tech craze over the last decade, the developments of such open and useful standards leaves a lot to be desired. Almost everything cool these days is some app with perhaps an api that is branded as a “platform”. We’re basically treading water.
There is much chat about real-time collaborative apps, but the reality is that most people are working async most of the time. If you start with the concept of offline first, with eventual consistency for collaborative work, you implement all of the same conflict resolution as if you are implementing a real-time app with conflict resolution. Then adding real-time collaboration later is easy.
This is where CRDTs (conflict free replicated datatypes) work better than OT (operational transforms). OT need more supervision from the server, the further you diverge from the servers state the more likely there will be a corruption. CRDTs are inherently designed to work with massive diversion and no central authority, really they are offline first.
[1] https://rxdb.info/replication-p2p.html
There are things you can never do on your laptop. Offline is limiting, in many ways. You know how I know? I grew up in the 90s. Online is a magical godsend of capability and functionality. Offline is cute. Online is what we dreamed of.
Should you have offline modes? Of course. Should you have some offline-first applications? Of course. Is offline just online with extreme latency? Of course it isn't. Use your brain. Think.
In fact, ad-hoc random person-to-person communications online are gatekept by "the algorithm" which would rather answer your question directly to keep you from meeting another warm body online.
https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum
The latency, however ...
A European station wagon with the rear seats folded takes 1555 liters, with 95% utility that is 6422 tapes. That wagon can hold 289 Petabyte of compressed data
From Amsterdam to Rotterdam, it takes about an hour to get your data to its destination. That is roughly 640 Terabits per second. For comparison, AMS-IX peaked at 11 Terabits per second last year.