315 karma · joined April 20, 2010
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
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.
I found docx to be a very well documented format and a surprisingly good fit for this.
https://tinycld.org has a live demo
We also have https://tinycld.org/llms.txt for writing packages and periodically test it's usefulness by one-shoting a simple TODO app: https://github.com/tinycld/todo
* 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.
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.
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.
I may be mis-understanding what you experienced though, If you'd like to provide more details and/or some screenshots please file a issue https://github.com/tinycld/calc/issues
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.
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
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.
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
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!
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!
Where were all these alternatives when I was looking for a WYSIWYG form builder?
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.
It looks like you started with Hasura GQL and switched to your own implementation (https://github.com/twentyhq/twenty/pull/156).
Would it be possible to comment on what influenced your decision here? I've built ontop of Hasura in the past and it's permissions model seems like it'd be a good fit for a CRM
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.
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.
I contacted them about any that looked promising and they send you a prospectus that listed the name and the financials. After signing a NDA of course.
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