Alas I envisage this being across many machines.
(I'll edit the previous post for brevity)
58 karma · joined April 22, 2008
You can email me at andym at the domain above.
Alas I envisage this being across many machines.
(I'll edit the previous post for brevity)
- 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.
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.
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).
This is perhaps a future topic, but to me it extends out of SSO:
Paul (@kiwicopple), do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase?
I suspect it's Cerbos or Casbin, but if you ever do it in house (and since you've nailed AuthN that makes great sense), my wishlist:
- It should be as simple as an API end point, .approve(auth.jwt(), Array<Role | Permission>). I.e. be available in Edge Functions, Postgres Functions, and anywhere else.
- Use a policy schema with the most industry support for easier acceptance/integration with the enterprise.
- Flesh out with enterprise-ready policy auditing tools, logging, etc. This is the real time saving for developers.
- I really recommend Tailscale's ideas for better RBAC in https://tailscale.com/blog/rbac-like-it-was-meant-to-be/
It gives desktop Gmail an RSS-esque topic view of your inbox, and lets you infinite scroll through emails like you would Twitter or Insta.
I start 99% of my emails with 'sorry' - I live in fear of going into my inbox, and so when I do it's a distinctly whiffy guilt laden experience, so I don't go in again for a while, and the cycle... well, you get the idea :-)
I've tried other addons to help (both using and making), but keep failing to invest the effort. In the end I went with "what's the simplest, speediest change that might have a lasting impact" and this was it.
It started as a weekend hobby in September, but I've been trying to polish it as more people have found it helpful. (This is hard work as I'm a dreadful aesthetic designer. It's more a case of 'monkey see, monkey copy the html').
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
(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!
It's not just another "todo list", it's really dealing with the pain of remembering the promises you make in email, and the fact email is used to discuss all the work we do, but is completely disconnected from our other management tools.
It's also obviously a positive thing that lots of innovative new products are getting involved: a single pioneer does not a movement make.
Disclaimer: I've been working on ActiveInbox for Gmail[1], first as a hobby project and later as a bootstrapped business, since 2006. In fact I think we were the earliest, certainly for Gmail.
Oddly enough the transition from hobby to business came about in a very Kickstarter way, but long before it existed -- early users simply wanted to give money to keep us going, we refused at first because it was a "hassle to deal with tax" (this is also long before Lean Startup: customer validation was clearly not something we were tuned too), and eventually set up a PayPal donate button.
And I'm really proud of our community - we've been discussing ways to improve email very openly since we started. They drive ideas, and we implement them to create a very experimental product.
I'd really like to write up our experience for HN, including the experience of getting an invite to YC, but not a place. There are a lot of stories of how regular people - our customers - pulled a business out of a geek hobby, and lots of mistakes and missteps I've made that could have been avoided.
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.
While the story is disappearing into time, and is perhaps an over-egged story of folk woman vs. corporate greed; there is a marked similarity between Elizabeth Maggie's "The Landlord Game" and what became Monopoly http://en.wikipedia.org/wiki/The_Landlords_Game (it appears an apostrophe is parsed out... it should be The_Landlord's_Game).
Its intent was to demonstrate how monopolies grow, and how once they exist they are hard to overcome. I.e. not fun. Which might explain something about Monopoly today :)
There's more at http://www.antimonopoly.com/original_boardgame.html
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.").
What IS interesting though is the potential to walk away from the advertising model to achieve less biased news. It's Murdoch, so it won't happen, but it would be a fascinating experiment. Shamelessly borrowing from Chomsky's "Propaganda Model" (http://en.wikipedia.org/wiki/Propaganda_model), mass media can never truly hold discussion & debate beyond the framework laid down by the interests of business. Whether journalists recognize it or not, there will always be limits on what they can say. Because to publish truly controversial material would be to terminate your public voice (i.e. no advertising, no revenue, no company).
The Web, with near-zero distribution costs, is the first time in history that it has become economical viable to escape advertising, by only needing to charge people a modest amount: the principle cost is investigative journalism, and there is a very helpful correlation between "well-connected Web user" and people who believe it is important to support an independent media outlet.
With a background in CS you have the functional hacker skills needed to create a first version of something, but you say your energy lies in marketing skills, so you know what 'something' to build.
I see this as one of the most powerful combinations seen in founders: the skills to get things done, and the soul to see the big picture of what problems people need solving.
On the flip side, the problem you have joining in with another startup is that the founders are often great generalists who need specialist help. Therefore a business/systems analyst is not an obvious fit with a startup, where the hacker-founders shoot first and measure later... at least until they've proven there is something there and they can mature their processes and goals.
22 Immutable Laws of Marketing - just the best overview for how to get out there (in the words of Steve Jobs, "it's a noisy world, the best you can ever hope or ask for is that just one single idea about what you do can be remembered"). Also might as well throw Positioning in there as its compliment.
Made to Stick - how to encapsulate a single idea, and hook it in people's minds
Founders at Work - a huge boost of motivation and some interesting individual strategies that people used, but light on useful tactics or broad strategies that you can action.
Not on the list, but I really highly recommend, is "Letting Go of the Words: Writing Web Content that Works" - an absolute bible for how to get your words on a website to be read and remembered.
Reference labels are essentially meta data - so you might create a general reference labels for invoices, receipts, meeting notes, etc. You can then use ActiveInbox's sidebar menu to drill into the knowledge base -> look for meeting notes for a given project, or invoices for a given contact.
If you're wondering, the background to that is that free gives you good email control and a full implementation of the essential useful features; and Plus increases your efficiency :)
As we refine features, and expand what it can do, I think we will become very useful to a much wider audience. (And thank you for the comment on cluttering - I will work through that with Pete, the designer - I absolutely agree nobody wants more clutter in Gmail!). Which is the time we will move away from highlighting GTD for new users.
Our goal with ActiveInbox is to deliver peace of mind (the guarantee that everything is prioritized and will be taken care of, and contacts will be impressed with your performance), and increase your flow to get through your email quickly & effortlessly.
And if you have any thoughts about what you like, don't like, or would love to see and want to discuss it more deeply, I'd love to go into it :) Just say hi at andym@activeinboxhq.com (or the community forum: www.getsatisfaction.com/activeinbox)... or here at HN of course!
1) instantly see emails when you reply to catch up on recent discussions 2) label-emails-as-you-send-them, so you can add tracking labels to the emails you send 3) right click any contact/label to see recent conversations
... and a few more besides, all customizable :)
For anyone worried about security - as I would be - it does not require any Gmail username/password as it works within the browser; and all XHR requests are there to see (and the source is openable, although it's minified).
And what browser are you using? We use a slightly different font on Chrome/Mac than we do on other setups...