That's extremely exciting news! Working LTE? No blobs? "Holy shit!" is an understatement.
Tangentially, what's an appropriate entry point for a reasonably capable C/C++/Unix systems programmer without prior mobile guts experience interested in working on software for this platform? I'm kind of assuming that'd be "grab a compatible device, clone postmarket, rtfm" but confirmation/pointers would be appreciated.
I hate to temper your excitement a little bit (I am excited too!), but I am not a bit surprised that LTE data works. Calling and SMS/MMS over LTE (for T-Mobile USA) are two things that at least that as of today, you need proprietary libraries to have it function on Android, and likely don't work on the Pinephone. I strongly suspect that other USA carriers will have the same issue (I say that because there are additionally several proprietary Verizon and Sprint blobs that are resident in factory images that need to be put in third party ROMs).
The Librem 5 has LTE mobile data as well, but it has those same issues (no VoLTE, SMS only over 3g, no MMS for T-Mobile USA). I am hopeful that between Purism and the Pinephone community that this is a solvable (but lengthy) issue.
Is that really where the goalpost is though? I thought everyone accepted that the modem itself would always be proprietary, and that was OK as long as it had a killswitch and no ability to directly interfere with the main processor or RAM. (The mostly-userland stack to drive the modem to send SMS etc. would be open.)
It seems right to me that the FCC et al shouldn't allow uncertified amateur radio firmwares.
"Is that really where the goalpost is though? I thought everyone accepted that the modem itself would always be proprietary, and that was OK as long as it had a killswitch and no ability to directly interfere with the main processor or RAM."
Most of the time when we speak about the baseband, we are talking about the telco network interface between your handset and the carrier ... and so it's tempting to think of the baseband as just some black-box modem that you can firewall yourself from.
However, the baseband processor also performs a number of real-time voice quality / noise cancelling / audio functions that really have nothing to do with the network interface, but are very important depending on how sensitive you are to call quality and things like echo, etc.
This is unfortunate because, like you, I would like to just wall of the baseband and use it as a modem and forget about it, but that perceptible difference in call-quality between "actual carrier" calls and VOIP calls is due to the baseband.
I believe that is all still true in the 2019 LTE era ...
Depends on the human defining where the goalpost is, what their threat model is and their philosophy etc. There are certainly folks who want open basebands enough to work on them, for example there are folks working on porting the Osmocom baseband codebase to Mediatek based phones.
VOIP over LTE has been rock solid in my experience with T-Mobile on the east coast. I regularly get on (hands-free) VOIP Zoom calls during my 20 mile commute and almost never have any latency or packet loss issues.
LTE latency is more than adequate for VoIP, with RTT latency to the tower being around 25ms. Adding another 40, 60, whatever, internet latency for VoIP is still well within the realm of good call quality.
Fair enough. I must have a shitty network. I see 150-200ms pings through LTE with occasional spikes up to 500ms, and any VOIP is both poor quality and we end up talking over each other because of the latency.
Don't all messaging apps like Viber, Whatsapp, telegram etc technically use VOIP, or at least the same type of technology as VOIP? The quality is quite good, for a lot of people.
T-Mobile USA's system is bog-standard IMS with RCS extensions. There are a few open source client stacks that support this, notably Doubango's. The trick is writing a frontend that uses regular Linux GUI libraries. As far as I know, nobody has done that yet...
Telepathy seems to be dying on desktop GNU/Linux, the existing clients in GNOME/etc are being replaced by protocol-specific applications. New protocol plugins seem to happen more in Pidgin/libpurple these days.
Well screw T-Mobile then honestly. This in addition to their (from what I understand) abuse of the FCC TV white space database kind of undoes any goodwill they had in my mind.
I don't know if it's just T-Mobile doing that. I've never tried using AT&T, Verizon, or Sprint with a purely AOSP (only compiled using the instructions on Android's website, not also including other proprietary blobls) or with my Librem 5, so I don't know if this is a T-Mobile only thing, or if it's industry wide.
Could I get more details on T-Mobile's abuse of the FCC's TV Whitespace database? I know they currently do spectrum hijacking with License Assisted Access in the 5Ghz band, I'm curious what their other abuses are tho.
Note that unlike other typical smartphones, this one has the modem as a separate module, so "no blobs" really means more that the FW for it is not easily accessible; but it's obviously there and working.
Tangentially, what's an appropriate entry point for a reasonably capable C/C++/Unix systems programmer without prior mobile guts experience interested in working on software for this platform? I'm kind of assuming that'd be "grab a compatible device, clone postmarket, rtfm" but confirmation/pointers would be appreciated.