469
points
samuelstros
Joined 475 karma
founder of opral.com
- Initial reaction: Looks too complicated & too niche of a problem to appeal to a sustainably large user group.
GDocs might be annoying to track who read the RFC etc. etc. but everyone is familiar with it.
I write RFCs, I share RFCs and your tool seems to require a substantial amount of buy in
- register
- unclear what the writing experience is
- outdated / overloaded UI
The last RFC I wrote was in hackmd (https://hackmd.io/Jjy-afCWS4CAFlHa62anMQ) because
- I wanted Markdown to store the RFC in git eventually
- Google Docs has issues with Markdown rouundtrips
- I didn't want to use git to write with VSCode (although... I actually did. I let CLaude Code write most of the RFC under my guidance, then put it into hackmd for easy sharing)
I hope the feedback helps!
- I recommend adding an installable executable. It seems like you are expecting people to clone your repo and then run it locally?
Take a look at Monitor Control how they structured their GitHub Readme and release page to download a dmg https://github.com/MonitorControl/MonitorControl
- does a framework like vercel's ai sdk help, or is handling the loop + tool calling so straightforward that a framework is overcomplicating things?
for context, i want to build a claude code like agent in a WYSIWYG markdown app. that's how i stumbled on your blog post :)
- can you elaborate on what versioning issues you are facing?
- 100% agree with the sentimment. markdown is hell as a format for editors :D
the effort it takes to serialize and parse markdown into an AST that rich text editor frameworks reliably operate on takes months. been there, done that. the majority of the engineering effort of building a markdown editor in the browser went into parsing and serializing markdown :/
Anyhow, we took the learnings from the Markdown editor app and created "zettel" as a result: https://github.com/opral/monorepo/tree/main/packages/zettel/.... The goal is to have an interoperable rich text AST—basically Markdown but with an AST spec.
- > The only reason people build “apps” in the browser to begin with is because it simplifies the development for the engineering team. Easier to ship, easier to update, write once, etc. Sometimes the user benefits, but rarely.
Interesting take. Usually web apps lower friction for users.
- no installations - no large binaries - collaborative - easy to adopt
I can't think of any (desktop) app that came out in recent years that specifically pitched "because native, we are better" and won. Sketch is a glaring example of a web app (figma) killing native (sketch)
- What makes you think the browser as OS is silly?
- nice, "run JS without (browser) runtime" is coming. perforr, jaws, or another project will eventually succeed.
- Why did you pivot away from localization?
See their old launch https://www.hackerneue.com/item?id=31166924
- That's a good tip. I was wondering how SQLite avoids page fragmentation. The answer is "it depends," but VACUUM is to the rescue.
What are your reasons for advocating for SQLite as a filesystem abstraction?
- Today i learned that HN has a nesting limit. @surrealize i fixed the username https://github.com/opral/monorepo/commit/7dc1f3c806bd89c6d68...
- Yes. The runtime was not affected. Hence, the ts-expect-error. Still nice to have the ts-expect-error fixed :)
- You are now forever in our git history https://github.com/opral/monorepo/commit/58734e11e51d8e20092.... the ts-expect-error was indeed fixed by your suggestion
- Yes. We looked at all version control systems (fossil, pijul, jj, git, darc, sapling). None provide what we need:
- target the browser
- supports any file format, not just text files
- understands changes, not just versioning of files
- suited to build web apps on top
- ultimately enable 1000's of artists, designers, lawyers, civil engineers, etc. to collaborate
we are 2 years into the journey. dec 16, we'll release a public preview
- the types kysely implemented are crazy. even custom where clause like this one [0] are typesafe :O
[0] https://github.com/opral/monorepo/blob/99356e577f558f4442a95...
- We also came around to dumping files into SQLite instead of dealing with the filesystem (and git) for the lix change control system. This article touches on problems we encountered: https://opral.substack.com/i/150054233/breaking-git-compatib....
- File locking, concurrency, etc., are problems that SQLite solves
- Using SQLite allows drumroll querying files with SQL instead of platform-dependent fs APIs
- Using SQL queries is typesafe with Kysely https://kysely.dev/ (without the need for an ORM)
- I wish we could talk about your use case later at Local Thirst. But ... I lost my passport and won't be able to make it. Another time!
- Yeah bummer that Safari and Firefox are blocking any origin file access for security reasons.
> when the company owning the DNS records for that origin goes out of business.
Likely not a problem. Local data in OPFS is synced with a remote server for collaboration reasons anyway.
> There's also the issue with actually having an executable that can just run without any external dependencies
Assume you target the browser as OS, then it's already possible to have an executable: Run the JS file that renders a UI. Related: We will likely have an app launcher demo soon for https://lix.opral.com/
- OPFS works in Safari, see this demo app https://csv-n2qj.onrender.com/.
What doesn't work in Safari and Firefox is (non sandboxed) access to the files of a user. OPFS is sandboxed.
- Webapps will work locally soon. Say hello to OPFS https://web.dev/articles/origin-private-file-system. Works surprisingly good, see this demo app https://fink2.onrender.com/
- Using lix change control to plot changes over time is a neat idea!
- Hm. Not convincing. Disclaimer: I am the founder of Opral (https://inlang.com/ && https://lix.opral.com/)
The idea of parsing source code to auto inject translations, especially while leveraging machine translations comes up every 2 months.
It’s not solving the problem.
The problem to be solved is change control. Doing translations is (surprise!) cheap compared to controlling changes. Changes referring to the marketing copy changed, the button label changed, a new screen has been added, etc. It needs one system that can track and control changes across apps, translations, files.
If change control is solved, localization boils down to managing CI/CD pipelines.
- While building lix change control I figured out that collaboration was/is the driver behind local to cloud. A secondary reason is compute.
If a system exists that enables (distributed) collaboration on files, the appeal of cloud-based software vanishes. Remote compute becomes possible as well.
At least, that’s the bet we are taking with lix https://lix.opral.com/
- Agree. What’s your reasoning?
- interesting. that was not the case in 2019 when i did a bit of data science.
- are you running into issues while building on top of git & github? i assume that you need to teach data science people git/github
- i assume that editing csv's is coming later? i can upload a csv but not edit it
That's what I meant with overwhelming / too niche.
It seems like you intend to productize the RFC process e2e. But most "time consuming" parts of an RFC process is the human stuff "Did you read this?" "Did you update the RFC again?" etc. That back-and-forth seems to be expressed by all the features you have in RFC Hub but:
1. That makes RFC hub complicated.
2. Requires buy-in from every party to participate in all of RFC hubs feature like "Yes, I reviewed it and pressed the reviewed button in RFC Hub"
1 & 2 combined make RFC Hub (likely) a very niche product. New users are overwhelmed. Existing users need to onboard new users (their collegues) though. Otherwise, the RFC process will fallback to just DMs on Slack. Only a few teams will have sufficient buy in from all team members.