Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

61–70 of 262 posts

Re: Bring Your Own Client

#61
post #50

Earlier quoted context omitted.

Can you imagine a world where you could only use a specific phone model with a specific operator? or where you could only send text messages to people that is on the same network? If we can regulate phones we should be able to regulate social networks.

When the iPhone originally came out in the US it was locked together with a 2 year contract with AT&T.

(Deleted my identical but less detailed comment)

Then again, this was never the case in the EU, where bundling handsets with a GSM subscription was banned.

But yes, we don’t have to imagine - and the change certainly didn’t come out of the goodness of the carrier’s hearts!

Re: Bring Your Own Client

#62
post #5

This idea suffers from the same problem federation does. It's harder to move a whole ecosystem. Makes it harder to innovate. Leads to centralized platforms outperforming these BYOC/federated/open options. Basically how Reddit replaced Usenet with upvotes and basic spam filtering. There's more on this from 'moxie https://www.youtube.com/watch?v=Nj3YFprqAr8 https://signal.org/blog/the-ecosystem-is-moving/

>...Reddit replaced Usenet... According to Wikipedia, Reddit was created the same year Usenet service was discontinued by AOL. Reddit "replaced" Usenet in the same sense that cell phones "replaced" telegrams.

Reddit also has tons of unofficial clients that interact with it. It’s not quite the same since you still don’t own the data, bit it comes close.

Re: Bring Your Own Client

#63

The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…

We need NPT for software https://en.m.wikipedia.org/wiki/National_pipe_thread

I don't know if this is a good example :) Anecdote: I recently wanted to extend the hoses for my tabletop dishwasher (the one that hooks up to your tap, not to the wall). It's 2 hoses with 2 connectors each, should be easy. But all 4 are different. After 3 trips to 3 different hardware stores, I found exactly 1 fitting that fits 1 (of the 4) connectors. I ended up slicing the existing hose and extending it in the middle, because that was easier than finding the right fittings. I thought about ordering them online, but that would assume I successfully identified them, which I didn't. Granted, I don't know anything about plumbing, but neither do the average person know anything about technology.

That said, I agree, standards are necessary, I just wanted to rant about NPT.

Re: Bring Your Own Client

#64
post #8
post #2

This strikes at something that people often WANT when they say "text files are better than the registry/binary formats" - they want to easily bring their own tooling to bear. Standard APIs let you do this - even if you have a "binary format" like MySQL or PostgreSQL (on disk) - nobody really complains about that because they have a defined API you can interact with.

Or SQLite, which I would recommend over some homebrewed text file format, see https://www.sqlite.org/appfileformat.html

Unless you like your database to take types as a little more than suggestions.

Re: Bring Your Own Client

#65

The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…

>I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me. Same can be said about gmail. In the…

I'm still using imap and smtp, unless k9 mail for Android is abstracting something else away?

Re: Bring Your Own Client

#66

The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…

>I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me. Same can be said about gmail. In the…

Why do you believe that? https://support.google.com/mail/answer/7126229?hl=en

Re: Bring Your Own Client

#67
post #52

I don't see Google Drive ever providing an API for bringing your own client; it will probably have to be from the other side. We already have OT and CRDTs for concurrently defining changes from each user and a way to merge them. There is also the Braid spec ( https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b... ) attempting to standardize state synchronization on top of which one can bring any client

> I don't see Google Drive ever providing an API for bringing your own client

In a way, they already have, since you can mount your Google drive on your local file system, and interact with the files from there. The problem lays with the proprietary Google Doc format.

Re: Bring Your Own Client

#68

The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…

>I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me. Same can be said about gmail. In the…

> In the old days, one can access gmail via imap/pop3

I believe it's still possible.

Also IIRC it required some adjustments from mail clients to the "imap as gmail sees it" protocol, like "one message being visible in several folders", since "folders" in imap sense were mapped to "labels" in gmail

Re: Bring Your Own Client

#69
There is a company called EditShare whose primary stock in trade is (or was, times do change) digital video server appliances. AVID sold such a thing, but it requires AVID software to work... and it turns out that film editors are about as persnickety about their choice of NLE software as programmers are about their text editor choice. So Alice may favor AVID, Bob likes Final Cut, and Claire uses Adobe Premiere. All three are competent editors and the director wants them all on the project. By using standard file sharing protocols like AppleTalk and SMB, the EditShare server lets them work on the same footage.
Post reply on HN