> So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
> They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
> From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
Is there anywhere public that there are writeups or roadmaps about this? I'm particularly curious about whether there will ever be an API for third-party clients.
What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
I acutally see the reduced burden that comes with actually sharing resources.
To extend the previous analogy: Valve didn't make desktop Linux viable on their own. A lot of it is owed to another self-interested actor -- Google -- through the reduced need for dedicated desktop apps (largely pushed by Chrome), and various enhancements to wireless and power management that were necessary to make it a viable mobile platform (directly benefiting Android/ChromeOS, but then spreading out to laptops and mobile devices in general, including handhelds like the Steam Deck).
You can see it on a smaller scale in ecosystems like Android -- where handset makers regularly contribute features from their UI skins upstream, so that they no longer need to spend engineering resources maintaining distinct versions of theming engines/notification badges/multiwindow/various other stuff.
On a related note this is an argument for open source models, not just open weights. I think a lot of the diminishing returns relate to the opaque nature of most models.
I don't think it needs to be framed purely as generosity. You just need a sufficiently self-interested actor that sees open ecosystems as a necessary part of reducing their own risk profile, relative to the alternative of complete reliance of a third-party business that can take an exorbitant cut and/or Sherlock them at any time.
Valve and SteamOS are a good example of what this idea looks like in practice. (Though they may also illustrate a third thing you need: a privately-run company, that has enough profit, and enough commitment from leadership to the company's vision, that they can make long-term bets without having to eventually bow to investors seeking short-term gains.)
Not to defend this, just to further observe the different nature of their marketing -- games also haven't historically had similar "rent" options in the first place. Timed demos are a newer trend, demos in general have usually been smaller sections of the content, and they typically aren't something you're paying for.
It kinda feels cyclical, tbh. Bang-for-buck entrant that's friendly to modders shows up in the market, enthusiasts flock to it, it chases a bigger market as it grows, and then it eventually fades out as it loses what made it special in the first place -- assuming it even makes it that far.
I also think of Essential and Poco when this kind of thing comes up.
> We’ve taken inspiration from other open-source projects that have taken a similar approach, including Wikimedia, Red Hat, Rust, Python Foundation, Apache, Mozilla, Linux, and Debian.
Yeah, I'm pretty sure these are all descendants of SnapDrop, but development or hosting or both seem to keep dying off the various forks every few years.
That one is, apparently, now owned by whoever also owns the zombie brand of LimeWire.
I'm aware these aren't mutually exclusive. To me, the bigger benefit of not integrating them is that I can just rotate in freshly charged batteries anytime they die, and don't have to care about being within proximity of a charger.
(I also find this important for gamepads, to the extent that I don't just opt to play wired.)
As much as it still pisses me off reading the Surface product head's comment that if you love USB-C then you love dongles -- while shipping a Mini DisplayPort connector -- I also think it's a waste that they didn't contribute their magnetic docking to the upstream spec.
We could have had a USB Type-M. (Or, alternatively, Type-F -- for "magnets, how do they work?")
See, I agree with this too. You wouldn't have to worry nearly as much about the random little things that are specific to just one device or another (IR blasters, the DAC on old LG phones, etc) if you could just plug in a second USB peripheral.
But what I'm more getting at is the other way around: that wireless headphones will already have USB-C for charging anyway. And that, particularly for larger ones (that have that port directly on the device, and not in a separate charging cradle), it really seems like a waste that more of them don't leverage that -- so that, again, you could use the headphones while you charge them.
I too am a USB-C maximalist, but with a handful of differences from OP:
- You lose me at "toothbrush." I don't want personal care items that have internal batteries at all, because they'll eventually die on me while the device itself (brush heads notwithstanding) is otherwise perfectly functional. I'd much rather keep rechargeable AA(A)s on hand for that kind of stuff. (I still haven't found a good electric razor for this purpose, though, and have actually just gone back to manual for the foreseeable future.)
- I don't think I could live off just one charging port, but would rather just ditch USB-A entirely.
- I'm using wired earbuds, with a standard headphone jack, but with the number of full-sized cans that are using USB-C in some way it baffles me that there aren't more or them (or any, that I've been able to find) that also support using it for audio input, so you you can play them while charging.
> They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
> From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
Is there anywhere public that there are writeups or roadmaps about this? I'm particularly curious about whether there will ever be an API for third-party clients.
What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?