Very nice and very inspirational for someone bootstrapping a startup.
The pages clearly defined what you are building and how to use it.
The explanation of platform fees makes sense, though it could more clear if the pricing examples are only based on those fees or are account limits to number of members or dues.
You might want to check your terms of service, they do not list a jurisdiction and have the placeholder [jurisdiction] instead.
Not launched, but building open source components and mucroservices with a closed dashboard and overall backend.
For instance, a Git-like DAG for a config service [1] that supports history and eventually forking and merging on top of PostgreSQL. This was broken out of the larger Go codebase and is currently AGPL3 as a placeholder while I research better licenses to use.
The overall idea is the "nuts and bolts" of a small startup/SaaS app, including metrics, IAM/auth, and subscriptions via a single API and React/JS SDKs.
I hope to do a Show HN on one or both in the near future.
https://github.com/mkj/sunset/tree/main/embassy/demos/picow is a wifi-ssh to serial impl for a rp2040. I've got it plugged into my home server's serial port. It's using cyw43 for wifi also from Embassy - dirbaio is prolific! There's some WIP in Embassy for bluetooth.
That repo has a few crates depending on each other - sunset is the toplevel ssh, sunset-embassy adds no_std async, then the async dir has std rust, with a commandline ssh client in the examples dir.
TipTap is built on ProseMirror. Basic elements of the editor are made in TipTap, while for more advanced use (tables, menus, integrating code editor) I had to tap into ProseMirror.
I'm not really familiar with Milkdown so I can't say.
Could the RP2040 ROM be adapted for RISC-V creating a defacto standard for emulating features that aren't implemented by the specific RV-variant?
I'd also love to see a big-little implementation with a Linux capable RV paired (gateable) with the above M4-class RV and the state machines from the RP2040.
I had the thought years back to layer a Wayland-like surface rendering protocol over X using an HTTP UPGRADE like primitive and XIE extended event IDs.
Basically it would transform the socket to this new protocol which keeps X atoms under a binary ID prefix.
This would keep backwards compatibility, with Xorg DIX replaced with a modern server implementation.
This could be modified to a heavy client approach where direct rendering can bypass the server. Or a client can takeover chrome rendering through an extension.
I've been trying to adapt it to an offline LLM model, probably a LLaMA-like one using the llm package for Rust, or a ggml-based C implementation like llama.c.
It could even be fine-tuned or trained to perform better and always output only the json.
This could be a good fit with open sourced tovera when that is released.
I like the idea of supporting natural language commands that feel more natural and don't have to follow a specific syntax.
It can also process general LLM requests, possibly using a third-party LLM like Bard for more up to date responses.
The pages clearly defined what you are building and how to use it.
The explanation of platform fees makes sense, though it could more clear if the pricing examples are only based on those fees or are account limits to number of members or dues.
You might want to check your terms of service, they do not list a jurisdiction and have the placeholder [jurisdiction] instead.
Best of luck with it!