Solidus VS Mastodon

github.com/solidusio/solidus (72k lines): E-commerce platform.

Not really basic, but Solidus.

In 2014, Floyd was lesser known as The Floyd Leg. Our website was on Squarespace for both its e-commerce solution and web hosting. A large part of our current success was realized by choosing to invest in a custom web application that’s built with Solidus. With our website no longer abstracted by a WYSIWYG ("What You See Is What You Get") editor, we partnered with Nebulab to handle full-stack web development. Solidus (Spree, at the time, before it was acquired, forked, and renamed) was recommended to power the e-commerce part of our application. The decision to go custom came after a successful Kickstarter campaign back in 2015 for the Floyd Legs—a set of four steel table legs that fastened onto any flat surface to quickly put a table together. We proved a market need for adaptable and sustainable furniture design. The co-founders, Kyle Hoff and Alex O’Dell, knew there were more product offerings on the roadmap as they championed Floyd to be the furniture solution for all apartment essentials. Fast forward to 2019, Floyd is seeking to be the furniture solution for the entire home worldwide.

I'd say Solidus and Spree are you best options rather than trying to roll out you own ecommerce solution.

Completely agree. Alternatively, I would look for an open source project like solidus https://github.com/solidusio/solidus

Solidus: https://github.com/solidusio/solidus/releases/tag/v3.1.1

Check out https://solidus.io/

Hey there! I'm about to set up a small eshop (expected around 50 orders/month) for a relative (an artist). I've contemplated what's available, and I'm not very happy with what I found.

- There's Woocommerce, which I've installed and tried doing basic setup, and it's too deeply bloated in the Wordpress ecosystem. My first impression from Prestashop was that it's going to be quite a similar PHP mess

- I don't want to get vendor locked-in with things like Shopify. They also don't seem to offer much design customizability (I'm a web dev and there's quite a unique design concept for the site from the artist)

- Searching GitHub for ecommerce, Solidus[1] looked quite promising, however, it also slightly overshoots the border of 'too complex' for me, and their docs on integrating a custom payments provider (a strict requirement - not US based) aren't really great

[1]: https://github.com/solidusio/solidus

So my question is: are there any borderline-pet projects I've missed?

I've been doing web dev for over 2 years now, so I'm also thinking about building my own almost-serverless solution. Is that plausible in reasonable time (wouldn't want to give this more than 2 weeks), or are there too many holes to fall into even though the sensitive part of payments is handled by a simple integration?

One more bit of info, together with building this, their whole web is going to be transferred to a new CMS, likely the Netlify headless CMS (IMO a very cool concept - no backend, frontend uses GitHub http API to directly commit any saved changes). Therefore ideally I'd love to integrate the products inventory into this CMS, which saves data into markdown + front matter, and then can be built into HTML or any JSON to be fetched by frontend - that's why I said almost-serverless.

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

Mastodon DMs have absolutely no privacy: https://github.com/mastodon/mastodon/issues/18079

For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.

Postmortem on what happened here: https://news.ycombinator.com/edit?id=39305884

The v1 API of Mastodon limits the size of the tree that it will expand for users who are not logged into the server: https://github.com/mastodon/mastodon/blob/main/app/controllers/api/v1/statuses_controller.rb . I am guessing that this or some similar limit applies to threads being returned to unauthenticated users of the web UI. It just arbitrarily stops expanding the replies at some point, including the main thread from the OP.

If a thread is truncated, users expect it to expand automatically and autoscroll when you hit the bottom. In my desktop browser, that does not occur, and there is no indication that there is more to see. This is the situation of the web interface as of Mastodon version 4.2.5.

The issue is very sensitive to observer conditions. If you are logged into the server, the behavior is different. If you use a Mastodon app instead of the web, the behavior might be different. As the tree expands, the cutoffs become different. If you look at the thread on a different Mastodon server, the tree is different because every server has its own view of the Fediverse.

HN needs a best practice for linking to Mastodon threads in a way that provides a consistent experience to HN readers. The average Mastodon server would be crushed by hundreds of HN readers grabbing the entirety of a huge thread all at once, so this might involve some thread-unroll-and-cache service. I tried https://mastoreader.io/ but it did not solve the problem.

Alternately, we push changes into the Mastodon web UI to warn users when they need to click to see more and assume that people will get used to the navigation.

Suggestions?

Fixed in Mastodon v4.2.5 https://github.com/mastodon/mastodon/releases/tag/v4.2.5

>You can defeat the Affero clause by putting the software behind a proxy, for example

Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?

[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

Mastodon is free and open-source. Go ahead and add the flag:

https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....

Didn't say anything about freedom of speech. And again: I'm not the one to talk to. I don't have any strong feelings on the topic, but if you do, you should take it somewhere that people who can do something about it will see.

I tried to find an existing discussion to help get you started, but couldn't. You can start one here: https://github.com/mastodon/mastodon/issues

It's easy to sit here on Hacker News and say "they should just..."

Coming up with a standard for an international project will be a long, noisy discussion. You'll tread on internecine conflicts you had no idea about. Old wounds from past related discussions will come out. People will soapbox.

This is why I have no interest in discussing it. It probably won't go anywhere in a place where it actually could. It definitely won't here.

I've written down how I set up my Mastodon server here. This includes some topics that seem not well covered currently:

- use nginx reverse proxy with the official nginx.conf [1], but with some changes needed for compatibility with docker

- use rootless docker, for security, together with bind mounts, for maintainability

- use compose, with some modifications to the official docker-compose.yml [2] that make life easier and are compatible with the reverse proxy

[1]: https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

[2]: https://github.com/mastodon/mastodon/blob/main/docker-compos...