Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

Post reply on HN
Print view View original

241–250 of 262 posts

Re: Bring Your Own Client

#241

Post by oblio »

swiley wrote: post #41
jasode wrote: post #25

>What would it look like to have a thriving ecosystem of third-party clients for Google Docs style word processing, which can all interoperate with each other, even supporting realtime collaboration? Well, based on decades of history of other complex file formats such as pdf, zip, and MS Office formats of doc, docx, xls, xlsx, etc... it would be a buggy mess. It didn't matter whether the format was reverse-engineered…

Maybe collaborate using markdown with stylesheets instead of word then. As for the mbox problem: on a normal machine that must be shared between multiple tools (at the very least: biff,lmptpd, and the MUA) if thunderbird can't interoperate that's a serious bug.

Markdown is both underspecified and underpowered as a markup language.

Re: Bring Your Own Client

#243

Post by kortex »

tomxor wrote: post #240
stupidcar wrote: post #11

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 think the focus here is on the wrong thing, the "app", which makes ideas like legal intervention and other distractions feel relevant. I think client interchangeability and ultimately user freedom is fundamentally about data driven design, look at all the examples: text is text is text... git is a file based graph of merkle trees. They are both highly abstract, portable, unopinionated data structures that don't des…

Exactly. But in this case that opaque data format is exactly the thing that enables live editing. Gdocs runs on Operational Transforms. There is basically no way to do OT without a ton of back end support which means tightly coupled APIs.

Martin Kleppmann has a great talk on CRDTs for distributed text editing. It is a hard problem. You also need a dedicated binary format (basically a table) but at least in this case it is a lot easier to use an open format with federated clients.

Re: Bring Your Own Client

#244

Post by KouAkitaki »

oblio wrote: post #241
swiley wrote: post #41

Earlier quoted context omitted.

Maybe collaborate using markdown with stylesheets instead of word then. As for the mbox problem: on a normal machine that must be shared between multiple tools (at the very least: biff,lmptpd, and the MUA) if thunderbird can't interoperate that's a serious bug.

Markdown is both underspecified and underpowered as a markup language.

There's the CommonMark spec: https://spec.commonmark.org/

It's still an underpowered language though.

Re: Bring Your Own Client

#245

Post by ssivark »

carapace wrote: post #156
throwaway316943 wrote: post #34

I’m reading Thinking Forth at the moment and there’s a part in the description of Forth about how it decouples words from their parameters and return types by only allowing stack manipulation. This means that all words share a common interface and so they’re infinitely composable. The reason I started reading this book is due to learning how WebAssembly works which turns out to be quite similar to Forth. It got me th…

Yup yup. I'm on the trail of just this using a purely functional Forth-like language called Joy. Your hunch is correct, you're intuiting the "Categorical" (as in Category Theory) nature of "point-free" format: http://conal.net/papers/compiling-to-categories/ > It is well-known that the simply typed lambda-calculus is modeled by any cartesian closed category (CCC). This correspondence suggests giving typed functional…

That Conal Elliot paper is being my current level, and I don’t see the relation to the comment about composability in Forth. Is there a simplified explanation somewhere? (Preferable less mathematical and more verbal, but I’ll take what I can get) Thanks.

Re: Bring Your Own Client

#246

Post by mindslight »

dandelo1953 wrote: post #229
mindslight wrote: post #192

Earlier quoted context omitted.

We can split the difference by mandating that whatever storage services are provided via "webapps" must also be provided via a plain API. Users shouldn't have their data locked behind proprietary javascript. This would create zero additional burden, as every webapp needs such an API for the front end to talk to anyway.

I'd like to see cold storage providers split from app providers. Strict enforcement policy on cold storage data warehouses. And sensible policy for the app providers, like not caching PII. Implement and enforce at the fed level using this division in a manner that is something akin to Glass-Steagall. Owning data should not be something providers can ever exploit. [edit]: I also think this could be used as a means to…

That seems like a stronger mandate, but I think what I proposed would actually reign in their power better than your proposed decoupling.

First, different services would still have to agree on data formats to interoperate. The ecosystem would be quite similar to windows file formats, and we've got plenty of experience seeing how that works out. It's better than what we have now, but not a panacea.

The bigger issue is that in addition to wielding data lock in, these companies wield network lock in. With storage decoupling, if I load up my own profile in a hypothetical "Facebook competitor" app and make a post, Facebook has no desire to display that post to users of its app that are my friends. However with my API proposal, competitor apps have the ability to publish directly on Facebook's site and be treated exactly the same as every other post.

Also, my proposal has a longstanding philosophical grounding that the abilities of computing should be available to all - companies shouldn't be able to insist on specific methods of usage that computationally disenfranchise users.

Re: Bring Your Own Client

#247

Post by carapace »

ssivark wrote: post #245
carapace wrote: post #156

Earlier quoted context omitted.

Yup yup. I'm on the trail of just this using a purely functional Forth-like language called Joy. Your hunch is correct, you're intuiting the "Categorical" (as in Category Theory) nature of "point-free" format: http://conal.net/papers/compiling-to-categories/ > It is well-known that the simply typed lambda-calculus is modeled by any cartesian closed category (CCC). This correspondence suggests giving typed functional…

That Conal Elliot paper is being my current level, and I don’t see the relation to the comment about composability in Forth. Is there a simplified explanation somewhere? (Preferable less mathematical and more verbal, but I’ll take what I can get) Thanks.

I don't know if it's written up anywhere like that, sorry.

The very brief section on mathematical purity of Joy in the Wikipedia article describes it but in (IMO) an unhelpful way: https://en.wikipedia.org/wiki/Joy_(programming_language)#Mat...

> In Joy, the meaning function is a homomorphism from the syntactic monoid onto the semantic monoid. That is, the syntactic relation of concatenation of symbols maps directly onto the semantic relation of composition of functions. It is a homomorphism rather than an isomorphism, because it is onto but not one-to-one; that is, no symbol has more than one meaning, but some sequences of symbols have the same meaning (e.g. "dup +" and "2 *").

> Joy is a concatenative programming language: "The concatenation of two programs denotes the composition of the functions denoted by the two programs".[2]

[2] "Mathematical foundations of Joy" by Manfred von Thun https://web.archive.org/web/20111007025556/http://www.latrob...

Re: Bring Your Own Client

#248

Post by TeMPOraL »

chrisweekly wrote: post #237
TeMPOraL wrote: post #139

Earlier quoted context omitted.

The surviving open protocols are like libraries: they were created before the space got commercialized. They got grandfathered in. If libraries didn't exist for centuries already, there is no way they could have been created under current intellectual property laws and IP economy. Similarly, new open protocols don't generally gain widespread adoption - and in the rare case they do, that's only because some companies…

Great points -- w caveat that RSS isn't dead! :)

Technically. Neither is XMPP :). It's just increasingly rare to see in the wild.

Re: Bring Your Own Client

#249

Post by dcposch »

jasode wrote: post #25

>What would it look like to have a thriving ecosystem of third-party clients for Google Docs style word processing, which can all interoperate with each other, even supporting realtime collaboration? Well, based on decades of history of other complex file formats such as pdf, zip, and MS Office formats of doc, docx, xls, xlsx, etc... it would be a buggy mess. It didn't matter whether the format was reverse-engineered…

> Some successful existing examples of client ecosystems built around open standards: [...] email clients

Yeah, the way they just casually slid that in there...

That example really cuts both ways.

Yes, email is fundamentally better than other messaging formats in one respect. Standardization gives it permanence and universality. There are many things we use email for where it would be absurd to use anything else.

But when you actually lift the cover on email, it is a crusty box full of hornets and spiderwebs.

The actual, in-practice email standard comprises:

- A weird, undocumented and ancient subset of HTML

- A weird, undocumented and ancient subset of CSS

- A motley assortment of supported attachment types. Multipart MIME. For the main message body, you can use any type you want as long as it's `text/html`

- A ton of headers. Did you know that SMTP FROM and the From line we all know and love are two different headers? Often containing two different addresses! Don't even look at threading/References/In-Reply-To, it will make you sad.

- And, of course, a bunch of overlapping bandaids to try to retroactively add authentication. DKIM, SPF, DMARC etc.

It is so bad that there's a whole ecosystem of companies that try to make it less painful, often with very brute-force approaches.

I once had to use an expensive tool called Litmus. They literally just run VMs for every OS + mail client combo, then show you how your email will render in each case. Haha try again, your CSS is broken on Win7 / Outlook 2013.

--

The same underlying facts that make it a great format as a user make it obnoxious as a developer.

Re: Bring Your Own Client

#250

Post by megous »

Too wrote: post #233
megous wrote: post #204

BYOC for shopping online would be nice. Exchange formats for product aggregators sort of solve one part of the equation. But ordering is still an unsolved issue. It shouldn't be that hard to do. You may need maybe 5 endpoints. Get all product data for the whole stock, get individual product images, get order requirements (can include terms and conditions, desired information for the order, payment options, human cont…

I think you forgot the API endpoints that will tell you how few items are left in stock and how many other users that are looking at this item right now. Not all stores would be sophisticated enough to implement such endpoint though but luckily it is easy to approximate in your client using stock=Random.nextInt(1,2) and users=Random.nextInt(50, 2000).

heh, if those are gone, good riddance. :)
Post reply on HN