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.
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.
I can't advocate Supabase enough. Their combo of openness and elegance in their platform leaves me (a developer/entrepreneur) feeling secure.
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.
My Gmail plugin is coming from the same pain (I subscribed to a ton of great newsletters, but they clutter everything human): https://www.getbreef.com . It's just my side project, and it's in beta - let me know if you'd like to try it.
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.
Turning Gmail into an infinite scroll like Twitter/Instagram. And grouping newsletters into topics to feel more like a RSS reader - https://www.getbreef.com
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').
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.
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.
This space of "handle tasks in email" is starting to explode since pg called it as a giant opportunity. Indeed, I believe Mail Pilot are launching their public beta soon - the timing makes me think these guys were (savvily, tbf) trying to jump in alongside it.
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.
I believe the fun-factor - or lack thereof :) - might have something to do with the fact that Monopoly's origins are supposedly as a warning of the perils of capitalism.
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 :)
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.").
It's notable that they expect to "lose 90%" of those subscribers when they end the current "£1 for a month" introductory offer, which is being pushed by a huge celebrity-endorsed advertising campaign on the London underground. So the actual figure is nearer 10,000 subscribers.
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.
That said, one huge area of interest would be to (re)specialize in "user experience measuring" to drive product iterations (similar to the hugely successful Sean Ellis). All startups are concerned with understanding their customers - and most suck at it - which would make such a role pivotal in startup success.
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.
(Caveat: As a hacker with an interest/need to learn marketing)
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.
Exactly, so today's email client broadly serves two functions: 1) to manage emails (which is to say, manage the flow of tasks that emails represent), 2) be a knowledge base.
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.
Alas I envisage this being across many machines.
(I'll edit the previous post for brevity)