4 ms·

> It's honestly so trivial and uninvasive of a regulatory matter it's ridiculous. At what point do you become compelled to start transforming your web applicat

> It's honestly so trivial and uninvasive of a regulatory matter it's ridiculous. At what point do you become compelled to start transforming your web application into an open protocol?

pydry 6y ago
Maybe at the unicorn mark.
barnabee 6y ago
Certainly any company that relies on “safe harbor” style protections or sells online services (alone or bundled with software) as a subscription should be required to fully open and document the protocol.
- AmericanChopper 6y ago
  But most SaaS companies don’t make protocols, they make web applications. So I’m not really sure what’s implied by these trivial-to-implement protocols. Having a functional and well documented API isn’t a protocol. An open protocol would be more like a situation where any vendor could implement an “iCloud service”, and any “iCloud client” could connect to any vendors service.
  - barnabee 6y ago
    I don’t agree here. A web application API, properly documented and exposed to any client a participant wants to use becomes a protocol for that service, there’s no difference between CalDAV and the Google Calendar web app’s API except that one is documented, rarely changes, and if offer by a service provider would generally allow any client that implements it to connect, and the other is undocumented and it’s probably against the terms of service to build your own clients. The goal should be to force every API for these providers to meet some minimal definition of a protocol, not to define government mandated standard protocols or force interoperability between services.
    - AmericanChopper 6y ago
      Your definition removes all distinction between the concept of a protocol, and the concept of an API. Google Calendar doesn't implement the Google Calendar Protocol, there is no standards body involved in determining how Google Calendar works, you're not free to go an implement your own Google Calendar compatible service, and Google can change Google Calendar without consultation with anybody. There is no definition of protocol where a single-service API, designed, implemented and published by a single party is a protocol. Google Calendar implements an API. If your argument is that companies should be compelled to publish good API documentation, and allow any client to connect to them, then aside from creating a completely unnecessary system of regulatory moats, and aside from using the wrong words to describe this idea, you're likely to run directly into a 1A violation.
xmprt 6y ago
I think smaller companies tend to have the most open protocols (to the point that it almost becomes a security risk) because they don't have resources to work on unnecessary obfuscation. The protocols might not be documented anywhere but if a website is able to access a backend endpoint then someone else will be able to access that endpoint too. Nothing in the parent comment says anything about requiring good documentation or 100% backwards compatibility.
- AmericanChopper 6y ago
  You seem to be talking about APIs rather than protocols.

> It's honestly so trivial and uninvasive of a regulatory matter it's ridiculous. At what point do you become compelled to start transforming your web application into an open protocol?

pydry 6y ago

Maybe at the unicorn mark.

barnabee 6y ago

Certainly any company that relies on “safe harbor” style protections or sells online services (alone or bundled with software) as a subscription should be required to fully open and document the protocol.

AmericanChopper 6y ago
But most SaaS companies don’t make protocols, they make web applications. So I’m not really sure what’s implied by these trivial-to-implement protocols. Having a functional and well documented API isn’t a protocol. An open protocol would be more like a situation where any vendor could implement an “iCloud service”, and any “iCloud client” could connect to any vendors service.
- barnabee 6y ago
  I don’t agree here. A web application API, properly documented and exposed to any client a participant wants to use becomes a protocol for that service, there’s no difference between CalDAV and the Google Calendar web app’s API except that one is documented, rarely changes, and if offer by a service provider would generally allow any client that implements it to connect, and the other is undocumented and it’s probably against the terms of service to build your own clients. The goal should be to force every API for these providers to meet some minimal definition of a protocol, not to define government mandated standard protocols or force interoperability between services.
  - AmericanChopper 6y ago
    Your definition removes all distinction between the concept of a protocol, and the concept of an API. Google Calendar doesn't implement the Google Calendar Protocol, there is no standards body involved in determining how Google Calendar works, you're not free to go an implement your own Google Calendar compatible service, and Google can change Google Calendar without consultation with anybody. There is no definition of protocol where a single-service API, designed, implemented and published by a single party is a protocol. Google Calendar implements an API. If your argument is that companies should be compelled to publish good API documentation, and allow any client to connect to them, then aside from creating a completely unnecessary system of regulatory moats, and aside from using the wrong words to describe this idea, you're likely to run directly into a 1A violation.

xmprt 6y ago

I think smaller companies tend to have the most open protocols (to the point that it almost becomes a security risk) because they don't have resources to work on unnecessary obfuscation. The protocols might not be documented anywhere but if a website is able to access a backend endpoint then someone else will be able to access that endpoint too. Nothing in the parent comment says anything about requiring good documentation or 100% backwards compatibility.

AmericanChopper 6y ago
You seem to be talking about APIs rather than protocols.