HN user

nathanstitt

315 karma

Hi, I'm Nathan Stitt. a software developer and creator of many things. Engineering manager at OpenStax.org, a large educational non-profit

I own a consulting company Argosity.com and write primarily Ruby, go, client-side JS, and iOS stuff.

Contributor to OpenStax, DocumentCloud and various other open source projects: https://github.com/nathanstitt.

My email is <first name>@<last name>.org

Posts4
Comments145
View on HN

It's pretty simple: I have a small company and we're using it internally. my hope by releasing it is that the ecosystem will grow and it'll become the best way to publish web apps (ambitious I know).

I do not know what you expect by "hardened server implementations", it's open-source and people will probably host it a lot of different ways? If you're talking about the various services it offers like imap/webdav, I'm using well established golang libraries which I hope are secure but I have not performed a security audit or anything like that.

Also not affiliated but my open-source tinycld uses docx as the backend storage for its text package. Supports _most_ of the features (including comments and suggestions) but is still very young. It has a golang backend that reads/writes docx and translates to YJS that the editor reads for multi-user access. Has web/iOS/Android support.

I found docx to be a very well documented format and a surprisingly good fit for this.

https://tinycld.org has a live demo

Yea I really did want to go Nextcloud because it is the battle tested solution as you note, but a few things held me back.

  * It's UI felt dated - which I agree is not an entirely good reason to not use it, but certain stakeholders in the org that will be using it felt it wouldn't be acceptable.
  * Collabera Office, which underpins their doc solution is kinda weird how it runs, everything renders on the server and then is displayed on the clients.  Not mobile friendly at all.
I did really like the ecosystem though and did consider just writing the plugins I needed for it. But then that went down a rabbit hole in itself with Php which I don't have fond memories of.

Ultimately it was a case of "be the change you want to see in the world". This is my opinionated answer to what an online suite of apps should work like for better or worse. I'm in a good spot where I have a small group of users who I'm close to that can stress test it out and yell at me when stuff breaks.

yep very true, everyone has their preferred stack, and greenfield is _always_ easier than maintaining years worth of past code.

I did look really closely at Nextcloud when it came time to leave Google apps. I really wanted it to work but also wanted:

* Realtime updates - Pockebase gives us this for free.

* A native app - React Native <- this one worked out but does cause pain with the web version, some things don't work _quite_ as well as a standard React ap would.

* Lightweight docs that work on mobile. Collabora is very full-featured but is also pretty slow. It remains to be seen if I've successfully here because we're only starting to use our docs "for real"

And also: I'm absolutely sure this has many bugs that I've yet to uncover. All I can say is that I am planning on using it for real-world business stuff so I'm sure we'll be uncovering and fixing them throughout the next year.

hah, so I've been fighting AI all the time as it tries to write all this on it's own vs re-using libraries. To me that's a much safer option, because the libraries all pre-date AI so I assume the authors know what they're doing.

Not to bag on Nextcloud but I do think that this is _much_ easier to understand and maintain, it's standard Go/React/Sqlite, nothing esoteric so if you did need to maintain it I'm sure anyone could pick it up. Of course I don't really know Php so that def flavors my opinions here.

I have an example of a one-shot TODO app: https://github.com/tinycld/todo just to demonstrate what's possible.

yes, I'm planning to support it indefinitely - my company (~10 users) just started using it so we're very invested in it's success.

I'd love for people to write whatever crazy packages they can think of for it so it has a rich ecosystem. It has the ability for admins to add a git or NPM reference into the packages list and install packages on the fly like wordpress supports.

As for hosting as a service, maybe someday. I also own the tinycld.com so who knows.

Good question, TinyCld does uses docx/xlsx files on the drive package as the native storage for text/calc. Drive is exported via webdav so doing so lets native clients load the files as well. Locking is used though so web & native _hopefully_ do not conflict.

Text uses https://github.com/ZeroHawkeye/wordZero to read/write the docx, parse it into a y-prosemirror and served with yjs to clients using https://github.com/skyterra/y-crdt

And Calc uses https://github.com/xuri/excelize using the same techniques but uses plain Yjs Y.Map/Y.Array using a sparsely populated table

yes, I should make this clearer: You do not actually host the email, tinycld uses a transactional host for sending and receiving. I also have a lot of scars from doing that in the past and I'm happy to pay someone else a few $$ a month for that service.

We support postmark right now (it has spam filtering), mailgun in the near future. Plus probably a pure smtp server for those who _really_ want to do it all themselves.

Yes, exactly that.

Personally I have several small (tiny really) companies where employees wear a few hats in them, this setup allows me to add people to org (and email domain) A & B while not getting C.

It is _not_ setup at all for billing or anything like that though, but that would be a easy enough feature to add

Hey all, Nathan here, I'm the author.

I wrote TinyCld because Google in their infinite wisdom decided to cancel my 20 year old free Google Apps suite for "commercial usage". Which, to be fair it totaly was, and I obviously shouldn't complain about 20+ years of free usage.

But _still_, that wasn't the terms I signed up under, and nothing is more irratating than a good old fashioned rug pull. How hard could it be, right?

TinyCld is two things, a self contained workspace like the one we're all familiar with (mail/cal/contacts/drive/text/calc), as well as an easy to extend platform that brings all the batteries you'd need to write realtime web+native apps.

And yes, I used AI to write a lot of this. (really, ~200k loc by one author is a pretty good tell) Some may hate on that and thats fine, I get it. But I did look at each commit and there is a lot of bugfixing and tweaking features back and forth that went into it. If nothing else, I've got some good stories to tell here and have learned a lot.

Stack: Expo (React Native + web) on the frontend, PocketBase + Go on the backend. Standard protocols (IMAP/SMTP/CalDAV/CardDAV/WebDAV) so native clients work as well.

I'm currently using it myself with a few friends but has not been widely used beyond that.

Demo (no signup): https://tinycld.org/ and click the big Demo button.

One-line Docker install: https://tinycld.org/docs/installation Build a package in 10 min: https://tinycld.org/docs/creating-a-package iOS app: https://apps.apple.com/app/tinycld/id6762420971 Repo: https://github.com/tinycld

I'm very interested in any feedback anyone can offer. I've got a looong list of add-on packages I'm considering, suggestions welcomed!

Hey all, Nathan here, I'm the author.

I wrote TinyCld because Google in their infinite wisdom decided to cancel my 20 year old free Google Apps suite for "commercial usage". Which, to be fair it totaly was, and I obviously shouldn't complain about 20+ years of free usage.

But __still__, that wasn't the terms I signed up for, and nothing is more irratating than a good old fashioned rug pull. How hard could it be, right?

TinyCld is two things, a self contained workspace like the one we're all familiar with (mail/cal/contacts/drive/text/calc), as well as an easy to extend platform that brings all the batteries you'd need to write realtime web+native apps.

And yes, I used AI to write a lot of this. (really, ~200k loc by one author is a pretty good tell) Some may hate on that and thats fine, I get it. But I did look at each commit and there is a lot of bugfixing and tweaking features back and forth that went into it. If nothing else, I've got some good stories to tell here and have learned a lot.

Stack: Expo (React Native + web) on the frontend, PocketBase + Go on the backend. Standard protocols (IMAP/SMTP/CalDAV/CardDAV/WebDAV) so native clients work as well.

I'm currently using it myself with a few friends but has not been widely used beyond that.

Demo (no signup): https://tinycld.org/ and click the big Demo button.

Install: https://tinycld.org/docs/installation Build a package in 10 min: https://tinycld.org/docs/creating-a-package iOS app: https://apps.apple.com/app/tinycld/id6762420971 Repo: https://github.com/tinycld

I'm very interested in any feedback anyone can offer. I've got a looong list of add-on packages I'm considering, suggestions welcomed!

Form to DB 2 years ago

teable looks very interesting, I hope you do follow through on open sourcing it.

Form to DB 2 years ago

heh, I'll throw my formial (https://github.com/nathanstitt/formial) project onto this thread. I probably need to update it a bit but it's been working well in production for 2+ years now.

Where were all these alternatives when I was looking for a WYSIWYG form builder?

Ah, yep that makes complete sense if you want to per-tenant schemas. My app is multi-tenant but all have the same schema. We use a customer_id column that's matched against the JWT's customer_id token to ensure that no data is shared inadvertently by a dev missing adding a WHERE clause.

Thanks for the SF link, that's quite interesting. It seems bonkers to me to throw away all the advantages of the RDMS but you can't argue with their success.

A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.

OpenStax | Software Engineer II | Remote | Full-time | https://emdz.fa.us2.oraclecloud.com/hcmUI/CandidateExperienc...

The OpenStax Kinetic team is searching for a full stack software engineer. Our frontend is React/Typescript and backend is Rails. It's a small team where you'll be able to have a large role in setting the future technical direction of the product.

Kinetic is a new open-source project that helps to connect researchers with study participants. You can read more (and participate!) at https://openstax.org/kinetic/. It's source code is fully available at https://github.com/openstax/kinetic

Have questions? I'm the engineering manager for the team and am happy to answer anything, my email is in HN profile.

OpenStax | Software Engineer II | Product Manager| OpenSource | Fully Remote

The OpenStax Kinetic team is searching for a Product Manager and full stack (React/Rails) software engineer.

- Product Manager: https://emdz.fa.us2.oraclecloud.com/hcmUI/CandidateExperienc...

- Software Engineer: https://emdz.fa.us2.oraclecloud.com/hcmUI/CandidateExperienc...

Kinetic is a new open-source project that helps to connect researchers with study participants. You can read more (and participate!) at https://openstax.org/kinetic/. It's source code is fully available at https://github.com/openstax/kinetic

Have any other questions? I'm the engineering manager for the team and am happy to answer any questions, my email is in HN profile.

Yeah I’m not a fan of the php, but I have written it in the past so don’t mind it that much. I’ve went through and updated it a bit but am forcing myself not to get sucked into updates that realistically wouldn’t add much value

As I’ll document next post, I’m writing new features in React with graphql. I’ve managed to integrate that fairly well without needing huge changes to the existing codebase