191–200 of 262 posts
The problem with BYOC client for Google docs / Figma is that the underlying data isn't simple plaintext, it's too complex, and the protocol requires things like operational transforms, so BYOC wouldn't make sense.
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. I think that is a bit much, I would m…
>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.
WYSIWIG rich-text documents are table stakes. Users have had them for 30 years, love them, and are never giving them up. Their layout (and thus their schema) are also incredibly complex by necessity.
Earlier quoted context omitted.
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. I think that is a bit much, I would m…
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.
That said, I would agree with such a mandate, as the costs are probably worth it.
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 Many things replaced Usenet. Usenet is more of a protocol (that uses NNTP) than a social media platform. If you're any way a systems thinker, you would know that protocols are more resilient than services .
I've got lots of small tweaks I'd love to incorporate into a Twitter client. Unfortunately, I think many of them would violate the developer TOS. For example: hiding avatars completely or generating replacement avatars using the username to remove any chance of internal bias associated with an account's avatar. Another one: hiding images by default and forcing you to click to expand/open to see them (no previews). A…
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.
Maintaining a stable API surface is a burden. That said, I would agree with such a mandate, as the costs are probably worth it.
(And if a company starts churning their API in bad faith, that's exactly the kind of thing courts are meant to figure out)
I've got lots of small tweaks I'd love to incorporate into a Twitter client. Unfortunately, I think many of them would violate the developer TOS. For example: hiding avatars completely or generating replacement avatars using the username to remove any chance of internal bias associated with an account's avatar. Another one: hiding images by default and forcing you to click to expand/open to see them (no previews). A…
Here's some example code from a web extension I wrote that removes promoted tweets: https://gitlab.com/t0astbread/no-promoted-tweets/-/raw/maste...
Earlier quoted context omitted.
Check that https://developers.google.com/docs/api/reference/rest/v1/doc... You have the full specification of Google docs documents and API to edit any kind of blocks inside
First, that’s not the full spec for Google docs. It’s missing many aspects of the environment. Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?
I'm curious of what is missing
> Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?
It is certainly not for plugins, as there libraries to call that API from python, ruby and others which are then not meant to be run in the browser.
My point, is that if you want to build an editor of Google Docs, then you can do it, there is an API to get the doc format and an api to make modification to that document
Earlier quoted context omitted.
One of the better examples still seeing widespread mainstream use is email, and this even applies to multiple stages throughout the email ecosystem: sending mail, receiving mail, managing mailboxes. Imagine if email wasn't cross provider compatible
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…