andymitchell

That is useful to know, thank you.

Alas I envisage this being across many machines.

(I'll edit the previous post for brevity)

Replacing Kong with Deno is a great step (and by simplifying the stack, in line with the elegance I love Supabase for).

- My request with Supabase Logs is that they're easy to format in ways auditors expect (i.e. similar to major tools). That would be a headline benefit, because:

[1] As your customer, I have an easier time with SOC2

[2] In turn, I can pitch that to our enterprise customers: "your compliance will be easier, as your policy and log audits with us will match your other vendors"

I'm going to shoot this to your support channel, but a little more tiny feedback:

- There's no local way for a webhook Edge Function to flag "--no-verify-jwt", which means my local test environment can't be consistent with staging.

- I'm having to use Edge Functions for webhooks despite Postgres Functions being more desirable, because either Kong or PostgREST always requires a JWT. I'm guessing the switch to Deno will make this solvable.

I'm not the OP, but I do have a request here too.

Disclaimer: I haven't built this yet (primarily because it's too hard today).

I want to build self-hostable servers, to give our customers the option of privacy and easier compliance.

In that arrangement, there'd be:

- Our main / central server, for regular SaaS customers. It also provides public assets ("knowledge bases" in this case, but it could be anything - even just licensing info) that all signed-in users have access to. This would be the iDP.

- Many self-hosted clones of our central server, per customer

Because the central server has the most up-to-date shareable assets, which might be ahead of any upgrade schedule a self-hosted customer has, they'd want their signed in employees to have transparent access to those latest ones too. I.e. without the extra friction of additional sign-in.

tl;dr the ability to offer our customers an easy self-hosted option of our Supabase platform (with limited federated access to central data) is highly desirable, now that even SMEs request better infosec. Doing it all inside a Supabase Docker - rather than mixing in Okta - is what makes it maintainable and easy to share.

--- EDIT ---

This use-case could be written more simply:

- There's a platform/app server (built on Supabase). Customers can optionally self-host it for their business.

- There's a data server (also built on Supabase, but not self-hosted), that provides shareable assets, even to self-hosted servers.

My goal is that it's _seamless_ for self-hosted users to access the data server.

So the data server would need to be an iDP.

My preference for Supabase to do this (instead of Okta), is because offering a self-hosting option is currently an intimidating maintenance burden, so fewer moving parts (no Okta) is desirable.

Thanks Paul, Oso looks great.

Re: RLS:

Pros

- The simplicity+security is hard to beat

- Supabase is built around it. I really want the purity of just one platform.

Cons (in order)

- Our enterprise customers need regular oversight of policy + logs for their compliance (and our ongoing relationship). RLS doesn't expose that afaik.

- RLS can't control access to API end points in places like Edge Functions (again, afaik). Same for any 3rd party systems you might have mixed in.

- In my experience, RLS has quite a few foot guns in it as schemas migrate and evolve (security gaps open up, or recursion bites you).

We make an downloadable product [1] that over its lifetime has been sold as donationware, freemium and trial-based -- three of the main variants that shareware evolved into.

Short answer: downloadable trial software is still viable... we're doubling revenue each year and supporting a team of 6.

Donationware (product is free for life, occasionally nagged for money). Lesson's learned: 1) It's no way to live, but a good way to start, as the userbase was at it's most vocal with feedback back then, when we were trying to hit product/market fit (perhaps because 'donation ware' felt much more community-spirited). 2) I don't have exact conversion numbers, but I do remember being surprised by how much an individual donated ($1 was the minimum, $30 the average, $300 the max). I've read studies since that if someone is asked to name their own price, they'll be much more generous (the downside being not as many people will pay anything at all).

We then tried freemium (features were restricted until people paid). Lesson's learnt: 1) Do freemium by resource constraints, not feature constraints (i.e. all features are available, but when you use X amount of data you have to pay). Because otherwise users just see a 'broken' product, and don't see the point in paying for something less-useful. 2) We also noticed that most people quit in the first two weeks, and almost everyone who didn't, paid. I.e. the 'free plan' was hardly used (related to the first point). Thus it was just a maintenance burden.

Now we have a two week trial, and then you pay. Lesson's learnt: 1) Benchmarked against freemium, conversion increased 4% in real terms (and 20% in relative terms). Mostly because it nudged the small % of 'free plan' folks from above into buying.

[1] www.activeinboxhq.com

If house prices cross a threshold where first time buyers can't afford to get onto the property ladder, they're forced to rent - driving up competition for stock & thus rental prices. (This appears to be affecting more & more people in the UK).

As I understand, from one of the early Gmail product managers, element class names are the most stable of all the 'fingerprints'. The Javascript data structures are quite stable, and the element IDs change pretty much every session.

(Source: I'm the author of the ActiveInbox Gmail extension, and at various times have spoken to Gmail engineers directly).

I agree a service would be a useful thing. A killer bit of value would be if it could workaround Mozilla's addon rules. (We actually stopped publishing on Mozilla addons, because if Gmail changed, we couldn't wait 10 days to be "re-approved" to fix it, and as mentioned by gkoberger, Mozilla really clamps down on dynamic in-app updates).

Ymmv, but if it helps... From the POV of an extension developer, service reliability is critical, and I'm not sure if there's enough GMail extension developers to be customers and make it economically viable?

If there is, I think the ideal service would taint DOM elements with class names to make the important things selectable (rather than a Javascript API to retrieve elements). That way, we could build our own selectors with fail safes to fall back on (and we don't have the security headache of incorporating your dynamically-updated code within our own protected sandbox. We can just share the modified DOM instead).

Whatever you do with it, I'm really impressed with how cleanly you built this kartikt!

I got the impression from a single conversation I had with Google back in January (please take this as the single data point it is), that they really did re-route the entire organization to focus on Google+, and were prepared to scale back efforts on Google Apps for at least a few months. For reference, the conversation was about them seeking 3rd party vendors to fill in the gaps in their offerings.

Hi pdx,

That's a very sensible question, let me take a stab at answering it.

So, for 99% of things, it's all stored on Google's servers. ActiveInbox is a lot of UI enhancements to create a new way of controlling your email, but it does it all with a clever use of Gmail's labels.

The only thing that relies upon the server is if you're a Plus user (including the free trial), to store your preferences on our server; and to store 'Conversation Notes' (a text box at the top of all conversations for planning next actions, a quick memo of what the entire thread is about, and links to related information if needed).

We are trying to figure out a way to do Conversation Notes purely with IMAP, but we haven't got a really fast/reliable idea yet, so we're sticking with our own servers.

But yes - for everything that is important to your organization, it's all labels.

I'm not convinced most bloggers start blogging with the assumption they'll do it for nothing :)

They think fame and riches! Or at least having the intellectual satisfaction of bestowing upon the world their opinion... but without revenue they cannot reach out to an audience, they cannot fund deep investigations, they cannot travel, and nor can they inspire confidence in whatever readership happens to stumble across them.

(The last one probably is solvable with a recommendation/aggregation service for new/independent journalists).

It is of course phenomenally hard to get people to pay for anything on the Web, especially news and opinions. But this is where it's worth drawing a comparison with Diaspora's funding: that $200,000 in donations is remarkable yet understandable, because a certain group of people want to support "big ideas" and freedoms... especially those with a political edge (and nothing is so overtly political as the freedom of the press, in Jefferson's words: "Our liberty cannot be guarded but by the freedom of the press, nor that be limited without danger of losing it.").