It looks like the relevant state law is missing in the ToS:

> These Legal Terms and your use of the Services are governed by and construed in accordance with the laws of the State of ________ applicable to agreements made and to be entirely performed within the State of _______ without regard to its conflict of law principles.

Also, not sure why you are loading your ToS in an iframe and making it non-selectable and non-copyable? Seems rather user-hostile.

Hello,DeLopSpot. Many ToS docs push skirmishes into one state. We are thinking it is easier for the customers to argue in the state the property is located. This is under advisement. The blank line is simply an oversight. Out of curiousity I will ask IT about the non-selectable/non-copyable comment. I suspect it has to do with speed. I am not technical. Thanks for your observations. Richard

not op, but most states have standardized forms that real estate agents are required to use. This is probably a place holder until those forms are ready, but given that the entire point is to make a legal transfer, that should probably be looked at :) another way to look at it might be that this is for the early adopters who are interested in splitting what would normally be 6% commission, like other 'for sale by owner' sorts of sites.

(in other words, this isn't really re-treading new ground, which is probably a good thing... there are tons of other sites that focus on actually closing a sale with very little commissions involved.)

gunapologist99, the forms are built into the product. They are simple forms to read and understand. I have answered thousands of consumer real estate questions and it is apparent by the questions they ask that many consumers are not reading the contracts. They turn to their trusted advisor and ask them if the doc is OK to sign. This is s very poor practice for consumers, brought on in part by the internet. The bulk of consumer do not read Amazon's ToS, or any other site. We don't think we can force people to read them, but if we make the purchase doc simple, and easy to read, they will read it. IMO, PropBox is breaking new ground. There is zero commission. Sellers are paying for an ad that makes the transaction easy by bringing the customers together instead of keeping them apart. A real estate transaction can be a win-win not a tug of war. Thanks for your review and your interest. Richard

This is an issue addressed by the Mastodon Server Covenant: https://joinmastodon.org/covenant

The Covenant includes a commitment from server admins to give users at least 3 months of advance warning in case of shutting down

That's an agreement with no teeth, they can just shut it down without warning, and then what do you do.

If this is very important to you, then you should find a server admin that you trust, such as a friend or a fellow industry professional.

You can also use a paid instance like https://cloudisland.nz/ or set up your own using a hosted service like masto.host

It seems that RSS feed generators are a bit like static site generators: it's often thought to be easier to make your own than to learn to use someone else's.

Anyway, here's another self-hosted open source RSS feed generator for arbitrary websites: https://github.com/hueyy/HungryHippo

Because the design of RSS/Atom put all of the complexity on the client (polling, state management, etc.) it's literally the same as static site generation. And by "the same", I don't mean "an equivalent but separate problem". I actually think having two separate generators—one outputting HTML, the other RSS—seems a bit wasteful. They're both parsing (presumably) the same content hierarchy and outputting it as SGML/XML-ish documents served over HTTP. One app should probably just do both (and it's easy to make your own that does)

This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed.

See https://sfeed.org. In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty.

Vinni, might you be interested in enabling the standard in Feed Me Up?

There already is such a standard! https://microformats.org/wiki/hatom

Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though.

(That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)

https://microformats.org/wiki/h-feed is the up-to-date version

I like this name better — the h prefix is cool in that it shows things are coming all the way from basic HTML.

Microformats, I see this is the proper way.

Ah thanks - been out of that world for a long time now.

Ah thanks, didn't know about hAtom, will investigate that.

I do think it's (much) easier to add some HTML classes than output an entire separate file.

I've been using Nuxt + Strapi as my new CMS stack, and while it's a big step forward in so many other ways, outputting an RSS feed is far from automatic.

I disagree. I find the it wasteful, that every source will implement their way of rendering data. If we ignore the ad-problem for a moment, I would love if RSS would be the output of every website and the client then renders HTML to achieve the best UX possible. No broken layouts, no distractions, no dark pattern, just content.

This is more less how Google Web Light worked.

I mean, it's exactly like a static site generator — I'd call it JAMstack, except the "API" is a plain HTML page and the markup is RSS :)

So yeah, definitely straightforward enough for a case of NIH syndrome. I think putting together the website took more time than writing the tool itself...

I created a automated HTML->Feed mapper [0], that simply analyzes the structure and offers you potential feeds.

[0] https://github.com/damoeb/rss-proxy/