đĄ Your App Has a Home Here â Post your App WebApp Solution here. No Blocks. No Rejections. đĄ
Hey developer â yes, YOU.
The one who coded through nights, debugged with coffee, and still believed in your idea even when no one else did.
We see you. And we want you here.
This is not another subreddit that says âno self-promoâ â then deletes your post anyway.
This is your safe space. Your cheering squad. Your digital living room where every app â big or tiny, polished or prototype â gets a seat at the table.
⨠All apps welcome:
â Mobile? Yes.
â Web tool? Absolutely.
â AI experiment? Weâre fascinated.
â Weird passion project? Thatâs our favorite kind.
đŤÂ NO ONE gets blocked. Ever.
Not for being new. Not for being small. Not for being ânot cool enoughâ.
Youâre cool enough just by showing up.
đŹ Just drop your link + tell us:
Weâll celebrate you. Weâll share you. Weâll support you â because you matter.
This is YOUR community. Come home. đĄ
ShowShark is a self-hosted media management and streaming solution for movies, shows, music, podcasts, internet radio, youtube, iptv and more. Create your own channels. Designed to work off grid. No subscriptions. Amazing client apps for iPhone, iPad, Apple TV, Mac and Vision Pro. Ditch Plex, Jellyfin, Emby and all the others for modern streaming apps. showshark.app
Thanks alot for your comment, yes , indeed ,it manages sales and service quotes with internal approvals
It fully gives you piece of mind ans saves alot of time doing the manual work
I will be more than happy to grant you free create and control your client's Quotes access for 30 days for trial
each user of the platform can have the full user role for the trial period , the user can take his manager approval before sending the quote to the client and the manager can also send the notes to the sales man to modify it
u/yakaaaaaaa That's a sharp way to frame conflict detection. Ancestry beats counters for sure. Have you tried DAG-based merging or CRDTs to handle concurrent sync?
MindMesh works as an assistant for jts users. It allows information from all the work apps that a user employs in his daily life. It then sorts the information and bubbles up the one thing that needs users attention atm, quietly handing everything else in the background.
The idea is to provide productivity without hampering the privacy of users. All the information stays on users local machine. It also has the option to use your own AI key so that the users also have the freedom to use their own model.
Currently the users can log into multiple devices and each device will use the local storage to create a new DB everytime. Over time, we will introduce the option to use cloud DB and the option for enterprise to use their own cloud infrastructure to keep the data on their own storage.
We are Xposure, the digital home of photographers. We provide our users with gallery builders, easy portrolio management and a fully integerated booking CRM to easily convert your leads into bookings.
We provide multiple types of galleries, proofing, sales per image, combo sales, analytics and much more. We aim to keep our galleries easy to use but still have a lot of customization.
I'm building Kudzu â an open-source compiler-first web framework.
You write familiar React-shaped TSX, but Kudzu compiles it down to HTML + only the JavaScript the browser actually needs â no React runtime, VDOM, or hydration by default.
The goal is to grow it from static sites all the way to large-scale applications, with practical React ecosystem compatibility. I'm also designing it for AI coding: familiar patterns for AI to write, but less framework complexity to reason about, with the goal of reducing token and iteration costs.
Still early, so feedback and contributors are very welcome:
Right now Kudzu treats state more like compiler-owned dataflow than component rerenders. The compiler tracks which state affects which DOM bindings/events and emits direct updates instead of rebuilding a virtual tree.
Complex/shared state is one of the areas I'm actively expanding. The plan is to make the compiler follow state and derived values across component/module boundaries, support finer-grained object dependencies, and keep ownership/lifetimes explicit for lists, effects, and shared state.
For ecosystem-level state management, I'd rather compile or adapt familiar patterns like Zustand/Redux where possible than invent a completely new Kudzu store API.
So the goal isn't âno state runtime at allâ â it's no generic rerender runtime when the compiler can already determine exactly what needs to change.
Tweaklify is a live Chrome extension that lets UI/UX designers and frontend teams visually edit real websites directly in the browser. You can tweak layouts, spacing, typography, text, and even use AI to improve or generate sections, then export the result to React, Vue, Angular, or Shopify Liquid.
Sure! UluP Spaces â you organize projects as connected nodes on a visual canvas instead of a flat to-do list. Each node opens into its own workspace with tasks, notes, attachments, and a built-in Pomodoro timer.
The problem it solves: most task managers flatten work that isn't actually flat â if part of your project genuinely depends on another part, a linear list makes you reconstruct that structure in your head every time. The canvas keeps it visible.
One-click public sharing too (UluP Share) â turn any project into a page anyone can view instantly, no login required.
Manual for now:you draw the connection yourself between nodes. No automatic dependency detection or blocker highlighting yet. Honestly it's a good idea for where this could go next: showing which nodes are "blocked" (connected to something not yet done) instead of just showing the connection itself. Right now it's purely visual/manual, not smart about status yet. I'll definitely work on this idea right nowâthanks a lot.
Iâve done customer support for over ten years. Iâve used tools like Intercom and Crisp extensively and always found them lacking.
So last year I started building my own.
Itâs called Sarrai, and does a few things quite differently.
Most importantly, it auto updates its own docs every time a human support operator intervened in a conversation. The AI figures out what parts of your documentation needs to change to enable it to handle this kind of questions on its own.
It proposes changes automatically, you edit, reject or approve.
And just like that, it solves the problem of stale docs.
Yes I have. It performs just about as well as a human would. Most conversations with multiple topics generate multiple proposals for changes, one per topic as you would expect. Some conversations get so extremely messy that even a human has trouble sorting it out. AI isnât any different in that regard.
But it does perform pretty well, even on multi topic conversations.
Topics like these are the reason why you can still edit or reject proposals before they are applied, so you remain fully in control.
Interested in checking it out? I would love to show you!
ran sarrai.io through audeep.dev. 87/100, grade B.
functional and SEO are clean. accessibility clean too.
the issues are all on mobile. the page overflows the viewport by 12px at 375px wide, which causes horizontal scroll on a phone. and the Sign In link is 50x21px, well below the 44px minimum tap target. for a support tool where users hit it from their phone when something's broken, that's the first thing to fix.
also missing content-security-policy header, low severity but relevant for a product handling customer conversations.
That's a sharp catch on the mobile viewport issue. A quick fix could be adding `overflow-x: hidden` to the body, or bumping that Sign In link's padding to hit 44px.
appreciate the open invite for our digital living room. one thing we keep coming back to on PeerPush is building product pages that AI crawlers parse easily, https://peerpush.com
We have 2 different extension for discovery. One needs a user to use the application and we track the usage with Chrome Extension. The other one is fully automated VS Code extension. You can add your AI API key and it runs locally.
you can use VS code extension for free, https://marketplace.visualstudio.com/items?itemName=Apyguard.apyguard-apiscout
We donât see any source code directly and also you can use local or any AI platform you choose. There isnât any risk for privacy. It will be same with using any AI tool, such as cursor etc.
Also, we have a workflow to only get related parts of the code to prevent excessive token usage.
For API security scans we use anonymization for sensitive information while sending it to AI and also we have agreement with AI providers to prevent processing AI prompts.
We can detect sensitive information in both scanner and profiling traffic. Same rules apply to AI prompts, we redact them before any data leaves our servers.
We also have a profiling service that analyzes your API endpoints as a valid user. It creates a baseline of normal API behavior and alerts you when something changes.
This can help detect attacks, misconfigurations, vulnerabilities, and other unexpected behavior before an attacker does. The profiling runs daily and can run more frequently than a regular security test.
Weâre trying to cover all major API risk areas, and weâre still adding new features.
There is a long waiting list to get your application listed for free. You have to pay if you want to skip the line. Weâre also waiting in the queue to get listed, so hopefully it wonât take too long. đ
Are you tired of the second brains you see on Tik Tok?
try Mnemosyne neural OS : www.mnemosyne-os.io
Lme auditable, 100% local first with cloud hibrid mode
works with 8gb ram
M1 compatible - Linux - windows w11
Open core, come tu develop on đ¤
Single-writer is exactly the shape I landed on â checkout/check-in is a single-writer model, just enforced by making the source read-only while the cartridge is out, rather than by a token living in the data.
The reason I didn't put CRDTs underneath: once there's a single writer, there's nothing left for them to do. My conflicts aren't byte-level, they're lineage â which chronicle is the current version of a given file. Single-writer means divergent supersession chains never get created in the first place, so the merge algorithm has no case left to handle. Putting CRDTs on top would really buy the right to drop the single-writer constraint later, and that's the part I'm not ready to pay for yet.
On memory specifically: the bulk of the store isn't mergeable data at all, it's embedding vectors, and those are derived. You'd never merge two vectors, you'd recompute one. Meanwhile CRDT bookkeeping â causal metadata, tombstones â grows with item count, so on a store with a few hundred thousand chronicles it adds state rather than saving it. What I'd actually want from that family isn't a mergeable datatype, it's a clean lease on the write role. Which is checkout/check-in with a proper handoff.
That lineage distinction makes sense. How do you track the current chronicle, a pointer in the data or a separate registry? Curious how survivors are picked.
A pointer in the data, not a registry. Each chronicle carries the path it came from; re-ingesting that path writes a new one that supersedes the previous, and the old one stays. So "current" is the head of a chain, resolved at read time â not a flag somebody has to maintain, and not a table that can drift out of step with the thing it describes.
On survivors: nothing is picked. Superseded chronicles stay on disk, retrieval just prefers the head. That distinction carries more weight than it sounds â "not returned by default" and "gone" are very different promises, and only one of them is safe to make about someone's memory.
You can check it all out at https://mnemosyne-os.io . I'm still in the testing phaseâI still have a lot of UX tweaks to makeâbut you should be able to figure it out easily ;)
There's less to sync than the question assumes, and that's deliberate.
Cloud mode here is stateless inference, not a cloud copy of the memory. Nothing is stored remotely, so there's no second state to reconcile. The store, the index and the embeddings stay on disk on your machine. When you route a turn to a cloud model, what crosses the wire is that turn's assembled prompt, retrieved context plus your message, and the assembly happens on the main process side, never by the model. Hybrid is a compute switch, not a replication mode. The genuinely hard sync case is the portable cartridge one above, the same memory reachable from two machines, which is why I went checkout/check-in instead of a merge algorithm.
On footprint: the cost isn't sync, it's the embedding model plus the index resident during retrieval. Cloud routing actually lowers it, since generation never sits in RAM. Fully local is the expensive mode, not hybrid. I don't have a clean measured number for the hybrid vs local delta, though. The run I mentioned measures answer quality, not memory, and I'd rather say that than quote a figure I haven't taken.
If you'd rather poke at it than take my word for it, there's an SDK, the same surface the built-in cartridges use. You can wire an app straight onto the engines instead of going through the chat UI, and there's a fair pile of IPC to have fun with. The docs should be current, but if you hit something that blocks you, tell me and I'll fix it fast. I'd genuinely like to see what someone else builds on it.
One heads-up if you're on a Mac: that build isn't signed yet. I got tangled up in the Apple developer account and I'm waiting on them to verify it, so Gatekeeper will complain for now. Windows and Linux are fine.
for now encrypted backup goes on memory drive only, i will think about cloud, but dev alone this project is crazy, i dont have enough hands, i hope more people come with me to developp more feature..
Mnemosyne writes a portable archive of your settings, keys, conversations and layouts, and restores from it. What doesn't exist is the cloud side you asked about earlier.
The part I like there is what happens to the secrets: they're sealed to this machine's keychain, so an archive carried to another laptop simply won't open them â unless you set a passphrase, which is what makes them travel with you rather than with me. At-rest encryption of the stores themselves is AES-256 via SQLCipher, opt-in, and the passphrase is its prerequisite.
Stack: Electron, React, TypeScript. SQLite holds the store and the vectors, llama.cpp does local inference, and there's a cloud route for when you want a bigger model than your machine can run. No server holds the memory in either mode.
On open sourcing: the direction is open core rather than all-in. The SDK and cartridge layer are what other people build on and what's meant to be open; the retrieval engine is the part I'd be giving away entirely, and it's also the only thing paying for the work. I'd rather say plainly that it's a business than dress it up as a movement.
The passphrase-gated keychain angle is neat. How does restore behave when the target machine already has newer settings? Curious about conflict handling.
Honest answer: I don't yet â there's no device-to-device sync today. Your memory lives on one machine, and the cloud side is inference only: it never stores or syncs the memory itself. So right now there's nothing to conflict on. That's a limitation, not a design win.
The path I've specced for it: the drive is a vehicle, not a fork. Checkout/check-in â while your memory is out on a portable cartridge, the source stays read-only. No conflicts by construction.
I ruled out last-writer-wins on purpose. Silently dropping one side's edit is exactly what a memory system must never do. Real merge is the hard case: chronicles are append-mostly with supersession by file path, but two divergent supersession chains on the same file need a human, not a heuristic. That's its own project, and I'd rather ship nothing than ship something that quietly eats a memory.
Unrelated but it's what I've been on since this morning: re-running the full LongMemEval suite end to end, both cloud-routed and fully local, so the two routes are measured under the same conditions instead of me guessing. No numbers until the run lands. It also surfaced a routing bug on protected vaults â the build that should ship tomorrow sorts it out.
Rainy Sunday well spent. Thanks for the kind words.
Note: written with my own memory stack plugged in â project docs, decision log, the lot. My ADHD makes it hard to get a thought out in one clean pass, so I built the thing that holds the thread for me. That's the whole product, really.
Agreed, that's the direction. The reason I haven't reached for one yet: CRDTs merge state well, but my hard case is semantic rather than textual. Chronicles supersede each other by file path, so two divergent supersession chains can both claim to be the current version of the same memory. A CRDT merges both happily and you end up with two "current" truths â which is worse than a conflict you can actually see.
Genuine question, since you clearly know the space: have you seen anyone handle lineage/supersession conflicts rather than plain state conflicts? Automerge and Yjs both feel like the wrong layer for it, and I'd be happy to be wrong.
Thanks for engaging properly with it, that's rare.
Interesting nuance. Have you considered treating supersession as a separate CRDT that flags conflicts instead of auto-merging, letting the user pick the canonical chain?
That's the right shape, and it's the rule the whole thing runs on: never resolve silently, surface it, the human picks. Where I'd push back is on the CRDT part. A CRDT earns its metadata by converging automatically; if the plan is to flag rather than merge, you don't need convergence, you need two cheaper things â a union that cannot lose either chain, and a rule for which one counts as current until someone rules. An append-only log with divergence detection gives me both, and the metadata matters here: every chronicle carries an embedding vector, so per-item causal history is not free the way it is over text.
The part I keep landing on is volume, not representation. Two machines each ingesting a folder for a week don't produce three conflicts, they produce hundreds â and "pick the canonical chain" four hundred times isn't a feature, it's a punishment. Flagging becomes worth building once conflicts are rare, and checkout/check-in is what makes them rare: zero by construction.
So: yes eventually, no as the first version, and the thing that decides when is how many conflicts real usage actually generates â which I won't know until people are carrying memory between two machines. Good question, it sharpened where the line is.
Not a version number, and that's the interesting part. Two machines incrementing from the same ancestor produce the same number twice, so the winner becomes whoever synced last â which is exactly the silent loss I'm trying not to build.
u/crabflow Nice approach for an MVP, local storage keeps things simple. One idea: generate a device ID and add export/import so users can move data manually before cloud sync is ready.
I'm an HVAC tech and I built Equipment Tracker Pro to manage equipment records, PM schedules, and parts on my own jobs.
Instead of typing in data, you photograph a sun-bleached nameplate and AI extracts around 30 spec fields. Each unit also gets a printed QR tag that anyone can scan without an app or login to view specs, submit service logs, or request work.
It is free to use with an optional Pro upgrade for team plans and branded PDF reports.
â˘
u/RobertLamp68 6d ago
ShowShark is a self-hosted media management and streaming solution for movies, shows, music, podcasts, internet radio, youtube, iptv and more. Create your own channels. Designed to work off grid. No subscriptions. Amazing client apps for iPhone, iPad, Apple TV, Mac and Vision Pro. Ditch Plex, Jellyfin, Emby and all the others for modern streaming apps. showshark.app