mickael-kerjean

I've spent the last decade building a Dropbox alternative that works on top of any storage protocol (SFTP, S3, SMB, IFS, GIT WebDAV, local disk, and literally everything else [1]) and its on github [2]

[1] https://www.filestash.app/docs/plugin/#storage

[2] https://github.com/mickael-kerjean/filestash

Working on a shared folder that syncs for agents, where you mount your existing data, apply controls / permissions and can monitor whats going on in real time: https://www.filestash.app/agents/, the code is in: https://github.com/mickael-kerjean/fdrive

> People really want to run agents on their data.

That's exactly the gap I've been working on https://github.com/mickael-kerjean/fdrive you mount your existing data, apply control / permission and can monitor everything the agents are doing with your data: https://www.filestash.app/agents/

distribution, a foothold in the enterprise, market share, brand recognition, ...

I have been working on a shared folder that sync between agents (https://www.filestash.app/agents/). The control plane [1] handles pretty much all storages protocols / platform (S3, SFTP, NFS< SMB, ....), you add the controls / permission boundaries and everything is auditable + traces, and the sync client is at the edge [2] to sync the data it actually has access.

[1] https://github.com/mickael-kerjean/filestash

[2] https://github.com/mickael-kerjean/fdrive

emacs is really something apart, by far the best software I ever had the chance to interact with, the closest thing we ever got of a lisp machine, a completly hackable, self documenting programming environment where you can change anything without limits.

It's unfortunate its underlying ideas aren't more widely used in our industry, the very idea that you don't need to expose a separate API for people to create and extends things since code is the api is a idea that put emacs on a league of its own .... Thank you to anyone who has been involved in developing it.

Also I would love to hear Stallman view of labs using (A)GPL code and not contributing back to the world since this is completly against not only the ethos of free software but what Stallman teached to the world about the very purpose of its license

Why would you assume that when they are violoting the very social contract that underpin the free software movement? I have published my oss work under the AGPL software that's used in production by millions of people because of Stallman's stance on free software, the very deal that is if you benefit from my code and use it from something, you must be open sourcing your code too and can't keep it behind close doors

Yes they can. I have been working on the filesystem part with the idea to provide a "a shared folder that syncs for your agents" https://github.com/mickael-kerjean/fdrive/tree/master/crates...

A few weeks ago, I stumbled upon an interview of Bernard Arnault who said "I work, but in the same time I have fun, this allow to work a lot without too much suffering". I was raise in the environment you describe and could never understand as a kid why people working in fancy job would not retire when given the choice, politicians are a fine example of those, well past retirement age but staying when everyone in my family would go on retirement the second they were given the chance since work was associated with pain, and the only thing that can explain that gap is the happiness factor

Yes. That's exactly what I'm currently doing with my sync client: https://github.com/mickael-kerjean/fdrive

The core contains the logic all the underlying platform uses and the platforms only handle wiring and ux

If you want something outrageous, I was fired as my dad was on his deathbed, he died before my 2 weeks notice finished and that created a lot of heat since I did not send them their laptop in my last day as I was busy preparing his funeral instead. They did not care, it was surreal, and I completly lost faith in humanity as a result

I work in this space with my oss work on Filestash, and its sync client https://github.com/mickael-kerjean/fdrive. A proper sync client is nowhere near a two week hackathon unless you vibe code it and don't have much care. I've been on it for 6 months and it's far from finished. Linux alone has a fragmentation problem. The sync engine can be shared, but the integration can't: tray, status, file manager overlays and notifications all work differently on GNOME, KDE, COSMIC, Omarchy, Sway. Electron looks out of place everywhere, so you end up maintaining one frontend per desktop, plus packaging for each distro. Then there's the sync itself, which is a long tail of edge cases, often platform specific. Last week I optimised the rm -rf case, FUSE hands you one unlink per file, so a folder with 10k files becomes 10k API calls unless you do clever things. Today, I've tried to optimise thumbnails, problem is the file manager opens every file in a folder just to render previews, so browsing a directory of videos can easily get uggly as well, let's not talk about the state of atomic save which if you are not clever here too will create multiple files on your server and waste bandwiths. There are many dozens of these edge cases just on linux and that's before you tackle window, mac, android, how do you handle delta sync ....

Having a path for a shared filesystem to be used by agents with strict access control is something I've been working on with my oss work: https://github.com/mickael-kerjean/fdrive, and https://github.com/mickael-kerjean/filestash

I have been working on exactly this with Filestash (https://github.com/mickael-kerjean/filestash), out of millions of users, 99% of them don't seem to care so much about the malleability, it gets very usefull when a company ask for something that 99.99% of people don't care without having to add yet another setting toggle. A recent example was when supporting gobd compliance deployment which required us to sign logs via a vendor who can deliver a qualified electronic signature for which nobody outside Europe would care about

Malleability is a great answer to avoid the death by a thousand feature where you bloat your software because a company asked for something 99% of your users don't care about. That's the path I went with for my open source work with plugins that can run from a wasm runtime to prevent those from doing crazy things [1]. Unsurprisingly plugins represent more than 10x the code than what the core provides.

[1] https://github.com/mickael-kerjean/filestash

> utterly unlike the sort of security in place already for power plants and weapons

As someone who has been working on scada used in those place from one of the biggest firm out there, I was shocked by how they released their software while working there, the thing literally went in nuclear plant but nobody published any checksum, + they were shipping hard drive al around the world full of the software ready to be deployed in those super sensitive environment to the marketing team to publish everything on their joomla website without 0 care to ensure the integrity ofanything. It was sloppy as hell, and while talking to the people who were doing those things, they either did not care, did not know or a mix of both saying there are other layer to deal with security in the chain. At some point I remember an accident in that same software that made a engine do things outside what it should have, that literally killed someone and the email we receive was along the line of: we know journalist are snooping around , you just shut the f up, I left soon after and that company valuation has gone nothing but more up

This got to be the extinguish phase from the EEE Microsoft playbook. Prior acquisition, Github was very liked and very focus, then Microsoft happened in their embrace phase, telling us EEE was something of the past. While trying to show good faith they extended the platform and this is now the very last phase

Filestash (https://github.com/mickael-kerjean/filestash) has a s3 gateway plugin that I made. It proxy the S3 traffic to any downstream storage: SFTP, FTP, another S3, SMB, NFS, IPFS, ...

There is this infamous xkcd (https://xkcd.com/435/) going like this: sociology is applied psychology -> physchology is applied biology -> biology is applied chemistry -> chemistry is applied physics -> physics is applied math -> math is way up there looking down on other fields

I would argue the main reason AI labs have been focusing on programming is to unlock industrial scale automation, next logical step is to solve math as it's the key to unlock everything else. Once you hold the key for math, everything downstream fields become a matter of compute

That's the path I've been on with my Dropbox alternative [1]. The 80% is the fast core that focus on file management, the remaining 20% is coming via plugins which implement one of core interfaces so you can handle your own storage, authorisation, authentication, custom apps to handle file types, ... Fun fact, there is 10x more code in the various plugins [2] catering to everything than the core code that was supposed to be the 80%, unsurprisingly everyone needed a different 20%. Plus I find it cool that the guy who needed a gobd compliant log system that have ton of properties to keep auditors happy enforcing hash chained signed with rfc3161 does not contribute to making the system shittier for everyone else

[1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/fdrive

[2] https://www.filestash.app/docs/plugin

Apart from learning, I cant see the point of spending that kind of money and energy to get such awfull token generation speed. Assuming memory bandwith is the bottleneck, is it just a matter of time until we start to see hbm4 based chip able to run qwen3.8 for normal people running at more than 500 token / seconds? Is memory speed the only technological bottlenecks that prevent us from having fast local model?

Kubo is absolutly amazing, is there a group of people interested in keeping kubo alive? If so I'd love to join that conversation

I am working on making the Dropbox launch first comment a reality: https://github.com/mickael-kerjean/filestash It gives you the Dropbox experience on any storage you want inclusive of FTP but also let you access your Dropbox storage via FTP, SFTP, S3, ...

Same as op, I rewrote away from react my Dropbox alternative (https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this:

  export default function component(render) {
      const $dom = xxxx
      render($dom);
  }

example: https://github.com/mickael-kerjean/filestash/blob/master/pub... the only library in there is rxjs to manipulate events in a functional fashion with no imperative code and everything is composed from those simple component functions. The wasm is used mostly as an interface for plugins to both run apps to display various file types like RAW, PSD, TIFF, CDR, .... as those tend to have better support in C than other languages, and on the server side to have a safe environment to execute plugin code.

> From Windows or Mac, this FTP account could be accessed through built-in software.

This is exactly what I've done: https://github.com/mickael-kerjean/fdrive https://github.com/mickael-kerjean/filestash

The premise of the article that "Dropbox was .. a feature, not a Product" is complete nonsense. Remember the infamous FTP guy's top comment during their launch? I have spent almost 10 years working on making that vision a reality [1], and there are entire industries built around some variation of it: digital asset management, managed file transfer, digital preservation software, electronic document management systems, ...

[1] https://github.com/mickael-kerjean/fdrive | https://github.com/mickael-kerjean/filestash

Any plan to release on ollama?

A Drobpox like app that works with FTP and every other storage protocol along gateways to access your Dropbox over FTP, SFTP, S3:

- the desktop client: https://github.com/mickael-kerjean/fdrive

- the web client: https://github.com/mickael-kerjean/filestash

> dropbox clone get off the ground

Thats exactly what Im working on:

- web client: https://github.com/mickael-kerjean/filestash

- desktop sync: https://github.com/mickael-kerjean/fdrive

In line with the infamous top comment during their launch, it does of course support FTP as a storage, and the other way around exposing your Dropbox as a FTP server, while supporting theme so you have a similar look and feel as well: https://www.filestash.app/img/screenshots/theme_dropbox.png + tons of stuff Dropbox never did

Genuine question: how reproducible / usable / verifiable are these architectures from the published documentation? Are they similar to PDF/DWG/PSD specifications, where the format look like an open spec at first sight until you attempt to implement it and realize the crucial implementation details are undocumented?