It does not need to interact with other Mastodon instances, but users on the local server should still be able to follow accounts on other Mastodon servers.
This sentence is in conflict with itself, follows are "interaction"
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
It does not need to interact with other Mastodon instances, but users on the local server should still be able to follow accounts on other Mastodon servers.
This sentence is in conflict with itself, follows are "interaction"
If you're just following you can use an RSS reader
This is not possible. The other servers need to be able to communicate with yours, and for that, yours needs a domain name.
If you only care about local users following other local users, and only other local users, then this is possible. But if you add remote users into the mix, you need to federate, and to federate requires a domain name.
Adding to why it has to be reachable: when a local user follows someone on another server, that server pushes new posts to your server's inbox, so the remote side has to be able to resolve your domain and connect over HTTPS. A LAN-only box can't receive that.
The least painful compromise is a cheap domain (or a subdomain you control) plus a tunnel or a small VPS acting as reverse proxy, so nothing on your home network is exposed directly. Then close signups so only your household can register. If Mastodon feels heavy for a handful of users, GoToSocial is much lighter on RAM for that use case, though you'd use a separate client app with it.
One thing to decide up front: the domain is baked into every account and can't be changed later without starting over.
~~littlefedi is out as of coupla days ago. still in early stage but should cover your use case. local binary, world comms via "lighthouses" don't need domain, vps, etc.~~ there's something strange afoot wrt the author's willingness to be forthcoming about the project's provenance. I'd stay clear for the time being.
GoToSocial is stable and famously light on server resources.
You can use a subdomain, and I'm pretty sure you can get a subdomain for free. It won't be pretty but it will do what you want.
ActivityPub doesn't work that way, but you can follow public Mastodon accounts using RSS.
Look into snac2 or littlefedi as alternatives for Mastodon if you want to save resources. Littlefedi has a specific use case to run off the grid
Have a look at GoToSocial.
I don't use Mastodon, but I don't know if it's possible to do this particular combination:
without owning a domain
users on the local server should still be able to follow accounts on other Mastodon servers
Like, a client that supports having accounts on multiple Mastodon servers would work. Then they have a local account, and they have an unrelated account elsewhere on another Mastodon server and follow people using that, so that the "following" has nothing to do with your local server.
But if you want federated behavior, where a user connects to your server and has their account there tell the local Mastodon server to pull down posts from another users somewhere out on another Mastodon server, you might need to have a certificate on your server that other servers recognize as valid, which in practice would mean one signed by a public CA.
I don't know for certain whether this is actually necessary, but I could believe that it is.
If you go really out of the beaten path, a client that only reads from other instances could use the RSS feed to go around the signed requests.
entirely within LAN
Wat? LOL