I'm building Cove (https://covereader.app), a native Mac app that works as a permanent local archive. Excerpt-only feeds get the full article fetched and extracted on-device in an offline WebView, stored LZFSE-compressed. It can also read articles aloud with streaming TTS that runs entirely locally, so nothing that you read leaves the machine. No account, no servers.

Caveats: Mac-only, no sync yet, will be one-time purchase at 1.0 (beta is free now).

Comments URL: https://news.ycombinator.com/item?id=43345861

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42472384

Points: 89

# Comments: 47

If you're interested in this space I'd recommend lurking in their CNCF Slack Channel https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/.

We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very similar just with using GitHub. We could even use GitHub Container Registry as the store as its OCI compliant.

Thank you for using Flipt btw!!

Feel free to send me an email at mark flipt.io, or drop into our Discord to say hi at https://flipt.io/discord

Will send over the project file now, very much appreciated!

Re: GitHub outage, each org gets their own instance in our cluster and maintains a checkout of the git state, so you can still write/read from your environments, they just wont be synched to GitHub until they recover.

We're also thinking about adding other 'sinks' like S3/object stores and OCI as backup sinks.

Another benefit is you can easily replicate the current (or previous) state of production/staging/etc flags locally just by doing a `git clone` and then run our self-hosted version locally. Its a single binary, can be installed with curl or homebrew and can read the flag state from your local filesytem.

This allows you to test your code locally or in CI with the same state in production

We could definitely look into supporting other types and making this simpler. The constraints that are matched can be of several types, which we try to parse at evaluation time https://docs.flipt.io/concepts#constraint-types.

Also thank you for the feedback about not being able to change the organization name. Currently we use the 'slug' of the organization (based on the name) when we setup the routes for your environment, so it was just simpler to make it a one time thing.

But I think we could support renaming your org, it would just make the previous URLs invalid, or we could maybe handle redirects on our end too.

We're working on personal accounts next, but due to GitHub API/apps permissions, we have to request a different set of creds to get that to work.

I'm the founder of Flipt, an open-source (https://github.com/flipt-io/flipt) feature flag tool that I (and others) have been working on for the past few years.

About a year or two ago we added support for serving flag state from various non-relational declarative stores like Git, OCI, Object Store, etc.

Many of our users came to love the git-backed storage, as it allows them to keep their feature flags close to their code in there organization's repos. But they had one (rather large) ask, and that was the ability to use the UI to manage flag state changes and still use Git as the backend.

So today we're rolling out our hosted solution that does exactly that (and more soon).

I would love any feedback, questions, etc, or if anyone would give it a spin! Happy to extend the 14-day trial as well for anyone interested in providing product feedback.

Thanks!!

Comments URL: https://news.ycombinator.com/item?id=41460061

Points: 93

# Comments: 44

If you're interested in attending its taking place on LinkedIn on April 17: https://www.linkedin.com/events/buildvs-buy-pickingafeaturef...

The thinking is we'll have some basic built-in policies (like admins can do X, editors can do Y, etc) but also allow users to configure their own policies if they want by writing rego and loading their policy rules at startup time (via config). We'd document the inputs that we pass to the evaluation call such as request headers, IP, role, etc.

I'm curious if anyone has ever tried something like this or similar?

[0] https://github.com/flipt-io/flipt

[1] https://www.openpolicyagent.org/docs/latest/integration/#int...

Comments URL: https://news.ycombinator.com/item?id=38016001

Points: 3

# Comments: 0