I'd like to see more attention put into carving out a subset of Mastodon's functionality that would allow you to host your fediverse node on a static site, à la blog feeds powered by RSS/Atom.
The discovery problem can be handled pretty straightforwardly: if you want notifications of replies to your posts, then that's just another feed that you subscribe to—a separate service. You don't exactly need an always-on "instance" providing an inbox endpoint to relay notifications to you.
You give up private channels (DMs), but you gain a lot more flexibility. It's a shame that there are so few server (and client) implementations for "the fediverse". We should have at least half as many options as we have in static site generators themselves. (In fact, with this approach, your preferred static site generator could become part of your "client"...)
Imagine your corner of the fediverse being reachable at $YOURNAME.github.io.
Ey, I made Fritter. The “fr” shamelessly came from my last name. Actually the cooler thing was Rotonde, which Devine of 100 rabbits fame made. Beaker has the ability to duplicate somebody else’s website, which we called forking. So Devine made a social website where the whole application was the website software itself.
Bear in mind that beaker sites are like mutable torrents. They’re just collections of files. The fun is that you can read and write those files by an API. The js in Rotonde would detect if you owned the site, and then present a text input which would write a new text file in the posts folder. The site would then use js to read all its own post texts and the post texts of followed users to produce a feed. To create a new “account” you would fork an existing site, copying all the application software. This meant the software itself was literally viral. It was really cool.
If you think a bit about it, you can probably guess the problems we ran into (both with rotonde and fritter). Most of it had to do with scaling - as all this occurred in the frontend of these p2p sites - and multi device coordination. There was, however, a pretty intense zen simplicity in the pattern of websites that wrote their own files with JS, and I wouldn’t write the idea off entirely.
> Most of it had to do with scaling - as all this occurred in the frontend of these p2p sites
You didn't say it, exactly, but just in case anyone who's reading casually misses it: this need not be the case with the static fediverse. I didn't mention JS or any sort of fully in-browser aggregator; nothing here requires client logic running on the "frontend" (i.e. in a Web browser). You'd be free to make whatever client choices are appropriate for you, including managing the whole thing via shell scripts (as many people choose to with their static sites).
I think a static site hosted on git is the sweet spot for the fediverse. It's realistic to expect an HTTPS 1.1 static endpoint and openssh to have << 1 unauthenticated remotely exploitable bugs per year.
This opens up a whole new world of hosting options. Think a raspberry pi that auto backs up to github/gitlab/git, with an ACME / let's encrypt client.
Stick it behind the right CDN and it could even host podcasts / video.
Enable automatic OS upgrades and give it a maintenance window and it's zero maintenance until the $35 hardware fails.
The difference is that dat, fritter, rotonde, and friends are p2p. There's no frontend in the traditional sense, just like there's no backend. It's all static files executed by a process. Imagine the same with .sh files and a shell executing them, all on your machine.
The static fediverse requires an always-on, network-available machine that is your data storage, your interaction with other people, and your data manipulation center, all in the same place
I don't understand your comment. What are you responding to, and what am I (or someone else) supposed to do with the information that your comment tries to convey?
I think rakoo was contrasting your observation as a "server-side vs client-side" distinction. As you said, in a server-side model you're using a server and you have a lot of freedom in how you manage the system. The p2p model in Beaker put everything in the client (the browser and thus the frontend js) and you're constrained to that model.
The nice thing about client-driven p2p is that the local-first model mirrors the intuition of using a desktop app, kind of like editing files in vim. Rakoo is overselling it a bit though, because the p2p network we used doesn't guarantee uptime unless you keep your device on. You might still want a caching supernode in the system. P2P also introduces coordination challenges with multiple devices, though the hypercore protocol folks are developing some answers to that now.
The idea you're discussing of dumb files on an HTTP server can work. There's a shocking amount you can accomplish if you just add the ability to enumerate files with range-queries (aka "list files in folder") though solving that with generated index files as in RSS is also fine, and a bit more flexible to boot. If your goal is to keep the server "dumb" then you're probably looking at a pull-based architecture -- again like RSS -- which reduces the amount of coordination between servers. This tends to mean you sacrifice discovery because you don't receive information you're not pulling, so a @mention or reply or subscribe by a random won't reach you. That might be a feature more than a bug for some. The solution is either to add push or to do some network-crawling. Secure Scuttlebutt does the latter along N expansions of the FoaF graph, which has a nice web-of-trust concept embedded in it. You could also go "full google" and run a service that crawls the entire network, then serve the crawled output to users, at which point you're pretty much at Twitter-levels of connectivity with a pull-based network.
The one other observation I'd make is that dumb file servers are most limited by the kinds of queries they can satisfy over the network. You can solve that either by crawling a site into your local index before attempting queries, or by trying to produce index-files on each server (which, again, is basically what RSS is). If you do the latter, I'd look into a file format in which range queries could be used so that a query can fetch a subset; perhaps using a fixed-length header and/or fixed-length records.
I know how Fritter works, I just don't know what we're supposed to do with rakoo's comment in the context of this discussion (esp. since the claim at the end isn't even true...)
> As you said, in a server-side model you're using a server and you have a lot of freedom in how you manage the system.
This is an aside, but: I didn't say that, and it's not how I'd characterize a backend-heavy ("server-side") design, like the current way the fediverse operates, but that's really an eye-of-the-beholder thing. I think of the dumb server approach as being the more flexible and convenient one if I'm putting myself in the shoes of the person wanting to publish—for several of the reasons you mention—which is the basis for my recommendation to define a static profile, after all.
PS: The discovery problem was pre-emptively raised in the original comment. The crawler approach is more or less sufficient (and something worth encouraging), but wouldn't actually be necessary. We're augmenting an existing network here that already supports push among accounts that don't deliberately choose to operate as static nodes. If Alice wants to respond to Bob, and Alice's client sees that Bob chooses to publish through a static node but is advertising in his profile the fact that he subscribes to the "Facebook Fediverse Feedsource" account, she can push a parallel notification to it. (Bob's choice to run his account as a static node doesn't have any implication for whether FFF is static or not—or whether Alice's is, either, for that matter.)
> indeed, the other is a proof of concept and will remain as is.
I've always said that a easy to deploy CMS is one of the missing pieces for the IndieWeb. Preferably it should work on any shared hosting. PHP/SQLite would be a good fit, but I understand if you have other preferences.
That doesn't sound like a static node to me, just another backend-heavy design.
Can I deploy this to GitHub Pages? NeoCities? Netlify (sans Functions)? If the answer is "no", then it really doesn't have anything to do with what I'm talking about.
I don't understand your first sentence in your comment. (It doesn't parse).
> How do you tell 'backend-heavy'?
Is there something confusing about the litmus test I gave in the comment you're responding to? What are the steps for deploying this thing to NeoCities? How would I use this to operate a node at $WHATEVER.github.io (where $WHATEVER is the name of my account or organization)?
A host capable of executing CGI applications—making it an active participant (rather than a passive one)—is exactly what I mean by "backend-heavy".
so be it then – while a rapberry pi can run a primitive webserver plus CGI but the services you mention require datencenters, heavy stacks and lots of smallprint in the T&Cs. Backends with millions of LOC as trusted computing base.
Seems I target something different than you. The world is big enough for both, I guess. And paid shared hosting (with a legal claim then) is common in Europe (except among Cloud-Hipsters maybe).
> the services you mention require datencenters, heavy stacks and lots of smallprint in the T&Cs
You're talking nonsense. I mentioned static sites.
It is not _more_ difficult or expensive to serve a static site with a Raspberry Pi than it is to get it to host a PHP application.
The project you linked to does not resemble in any way the thing that I described. It is worse than irrelevant. What sucks, though, is that it took three comments before you even partially acknowledged that you're talking about something completely different, despite what your original response to me indicates.
To allow people to review their followers before accepting them ("follow requests") all subscriptions in ActivityPub require the followed actor to send back an Accept activity. This, and the Webfinger requirement to confirm the username@domain address that predates ActivityPub, preclude plain static sites from being followable actors as seen from Mastodon. Although nothing prevents you from publishing a static feed in the ActivityStreams format, this would require a different, feed-like subscription mechanism where the publisher is not aware of subscribers and the subscriber has to poll the publisher periodically.
"Follow requests" are typically used for sharing private posts in existing social networks: that's why there is a "request and accept" flow. They seem like they should be irrelevant to users who only post content publicly. Does Mastodon require users with public posts to "approve" each of their subscribers?
Seems like GP is right then about some tweaks being advisable. There's no reason why ActivityPub servers should not be able to poll and republish ActivityStreams pages if the server admin arranges for this.
Yes. These are all assumptions of the sort that I'm saying would need to be (and should be) adjusted (i.e. fixed)—in Mastodon and ActivityPub, to better accommodate static nodes (not for the relevant desiderata to be adjusted to accommodate what's currently wrong with the design that Mastodon implements).
> I'd like to see more attention put into carving out a subset of Mastodon's functionality that would allow you to host your fediverse node on a static site, à la blog feeds powered by RSS/Atom.
You could just serve standard ActivityStreams; this can happen statically and is not something that Mastodon itself needs to be concerned with, obviously. A different component (either Mastodon itself or some separate thing) would poll known ActivityStreams endpoints and either expose them directly in Mastodon or relay their content via ActivityPub in a way that a Mastodon instance can support.
I'm pretty sure there are tools that allow people to subscribe to an activitypub feed of your private blog similar to RSS, it's been a while since I dived into the world of activitypub community projects and tools but I am certain I saw something like that somewhere.
> there are tools that allow people to subscribe to an activitypub feed of your private blog
Those aren't relevant here. You're saying, essentially, "static sites/blogs, squeezed through a Mastodon-/ActivityPub-shaped hole". I'm saying, "Mastodon profiles, squeezed through the static site/blog hole (in a typical staticgen pipeline)". They have some words in common, but the resemblance ends there, at the superficial level; they are otherwise completely opposite ideas.
> I am certain I saw something like that
Assuming that "that" means the thing that I'm describing: you wouldn't have seen that, because the relevant Mastodon-interoperable parts of ActivityPub as they currently exist are fundamentally at odds with the ability to do this, for reasons mentioned in part by Gargron upthread.
The WebFinger thing is a big part of it. Mastodon's not alone here; there are other WebFinger-dependent protocols (like remoteStorage) that also suffer. This is covered in <https://github.com/konklone/jekyll-webfinger/tree/9bcb46bbab...>. (Mastodon has taken off in a way that we could probably say it has reached critical mass, even if it's still not as mainstream as Twitter, but remoteStorage not so much.) This is a design flaw at the protocol level, and my contention is that it impacts further adoption more than people realize. There's no good reason, for example, why when I encounter a remoteStorage-compatible app where I only ever intend to grant it read-only access, I shouldn't be able to give it the URL for a dataset hosted on a static site. Presently, however, you cannot—unless the application author deliberately implements some workaround. But they shouldn't need to.
I don't want another Twitter-but-reinvented. I want a Mastodon-interoperable "profile" to be enshrined in a standard that projects currently focused on compatible ActivityPub-based client/server implementations agree to support because it's a good compromise that allows people to participate with nothing more than the ability to publish a static site.
ActivityPub is so poorly/vaguely specified that basically every real world implementation follows what Mastodon does, so good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone.
> good luck with trying to get what you're after without being at least indirectly dependent on the decisions of yet another Twitter clone
Not what I meant. The correct way to read what I wrote is with emphasis on "another Twitter-but-reinvented".
We already have have a Twitter-but-reinvented (Mastodon, and Mastodon-interoperable ActivityPub clients/servers). And people actually use it—which is the hard part of working on any kind of "social" gewgaw.
To think that we should throw that out and use twtxt or something like it would be to screw up bad. ActivityPub is better at being RSS-/Atom-like in its ability to convey structure than twtxt is, anyway. What's left is slicing it up, fusing the gaps and some now-necessary pieces with epoxy, and saying, "Here's the 'static' profile; you can look forward to support for this in Mastodon 4.0 [and everything else that tries to be interoperable]."
Yep. It was the same before Mastodon, with the predecessor of ActivityPub, et al. People had to "do whatever StatusNet/GNUSocial is doing". Even the code examples in the specs themselves were unable to interoperate with any instance whatsoever.
ActivityPub is supposed to be a generic feed format but in practice it's used mostly for Twitter clones so none of its non-Twitter vocabulary or flows have ever been developed.
The mechanism used to actually service publication requests from the person controlling the node is orthogonal to doing the design work to specify the thing and the political/social aspect of getting people to agree to support/adopt it. So, in a word, no.
(Side note: any design that necessarily depended on GitHub Actions or something with equivalent power would be a failure on the goals I've outlined.)
I can see where you're coming from, but just as food for thought, I think this is an interesting angle:
1. many people are able to host their content on github now (or gitlab or otherwise)
2. github (et al) provides a simple way to add RSS to your content
3. github actions provides a simple way to poll and update
Mastodon is very interesting, and it has gotten simpler over the years, but I don't think it is simple enough.
I think the argument is that it should be trivial to host on github / github actions, or anywhere else, just like any other sane static site generator.
Well, yeah. That's pretty much the thesis of what I wrote—hence, "Imagine your corner of the fediverse being reachable at $YOURNAME.github.io." (Are you trying to convince me here of something I was already convinced of? That's what it sounds like.)
WriteFreely is no more relevant to static sites than Mastodon is. They're both "backend-heavy" servers—not tools for creating the sort of content that can be hosted on GitHub Pages or Neocities or Netlify (sans Functions) or a simple host that serves content from the file system using Caddy/Nginx/Apache/etc.
> Discoverability has always been a hot topic on Mastodon. Discoverability makes or breaks a platform, as there is nothing more important to retain a new user than to let them find something interesting to stay for, as soon as possible. In 3.5, we bring a new explore page which features currently popular posts, news stories that people share a lot, trending hashtags and follow recommendations. Furthermore, for the first time, we attempt to bring people content in their own language.
An algorithm to rank posts and people? Did we learn nothing from twitter?
Honestly, an AGPL'ed, fully transparent, shareable, forkable and self hostable algorithm to do this is a whole new ball game. Where it will land us remains to be seen but compared to the current state of affairs I want to find out.
I think that depends what is baked in...using an algorithm to seek things one actually explicitly ask for/configs for, versus something that gets more oblique and "predictive" or makes decisions FOR you...let's give the code a look and decide after we actually scrutinize it, rather than just assume it's reimplementing the same problems again.
Yeah you're right, I think the larger problem is an algorithm that "learns" from the user, it's a positive feedback loop that produces nasty results. A simple ranking algorithm, especially one we can look at, would be interesting.
Something to consider though: even a simple ranking algorithm is going to influence social behavior on the network. I highly doubt most people will use the firehouse feeds with this option, and once you go down this road you begin talking about social impact. It's an interesting experiment, I'm not so averse to it now, but I'm wary of it still.
Another redeeming factor is that it's not personalised, allowing for it to be researched, and preventing people getting rabbitholed away from their peers.
What we learnt from Twitter, and Facebook, and (I've never worked in those two, but I've worked in other companies) is that ranking posts in general increases user satisfaction, and how often they return.
I realise there are a number of tech people who hate it, and it should definately be configurable, but companies aren't doing it to be mean, they are doing it because it works.
The metric for "it works" is whether people successfully get started and continue to use the platform. For commercial companies this coincides with them making money. Even though Mastodon is a non-profit and does not and has no way of making money from having more users, it is a valuable goal in itself. Each new user decreases the network effects pull of commercial social networks and increases the usefulness of the network for everyone on it. Especially since the userbase is never static as people leave due to natural and unnatural causes, it is important to keep an eye on new user retention.
I think we both agree there are things that Mastodon should never do, even if it increases retention, like highly addictive features.
A line needs to be drawn somewhere, and it is not clear to me that Mastodon did, as a project; because it keeps pushing what I (and other early adopters) consider anti-features in the name of new user retention.
For example, trending toots would have been unthinkable four years ago while trending tags were being designed, but trending tags eventually led to that.
The OP release notes announced "As we value safety, these new features come with their own moderation tools–nothing will show up in trends unless reviewed by one of the server’s moderators first."
Their metric isn't user satisfaction, it's user engagement as a proxy for user satisfaction, so says the sales pitch. It's obvious at this point it is not a sufficient proxy. Slot machines have a high user engagement and return rate too.
I run a mastodon instance [0] (themed to look like Windows XP). Overall I really enjoy mastodon (and the fediverse in general), it gives the user an opportunity to carve out their own niche through their own instance, while still being able to interact with the overall system.
There are still some challenges with setting up your own instance (I couldn't get the docker image working, the documentation for setting up a dev environment could use some improvement, and email confirmation is difficult without using an external service), but think this will improve over time, and there are managed services you can use to run your own instance.
As a curious bystander, I am very excited about both the social/ideological and technical merits of Mastodon, but I would never use (what appears to be) a Twitter-like format myself. I prefer content-centric over people-centric and medium/long form text over short form. Even Facebook was a better fit for me, in certain situations (primarily private groups) than Twitter is.
Does anyone know (1) if the current Twitter-like format is due to an explicit affinity towards it within the community - or due to some other reason and (2) will Mastodon allow for other formats in the future in some shape or form?
The activitypub standard isn’t limited to tweets. There are Reddit-like and YouTube-like implementations.[0]
The privacy would depend on the server rules. You could have a long/medium form blog that is federated using activitypub.
But there’s a significant technology toll to pay to get these up and running in my experience. It’s still not like signing up for Twitter or facebook. Which probably makes for better communities once you’ve managed to make it inside.
@klabb3 The underlying protocol - ActivityPub - does not have the same limits imposed by proprietary platforms (e.g. Twitter, etc.). Most constraints that exist on platforms like Mastodon, etc., are usually decisions made for a partiocular purpose (e.g. any character limit on posts in Mastodon is becausse the intended function of Mastodon is for microblogging, etc.). Different platforms in the fediverse - that leverage ActivityPub protocol - implement different constraints for similar reasons; namely, choice.
That being said, for your interest on content and less on interactions - if i accurately understood what you're asking about - may i suggest looking into the write.as platform. See https://write.as/about One can self-host this if inclined, but there's also a paid plan thrhough this company...but the gist is that its designed for much longer-form blogging (and other related functions too)...but still leveraging ActivityPub undernath which could be used for interactions if desired...but its core premise is much longer form blogs. I'm sure there may be other long-form platforms, but this is the one that comes to mind for me (at least for leveraging protocols similar to mastodon). Cheers!
> As we value safety, these new features come with their own moderation tools–nothing will show up in trends unless reviewed by one of the server’s moderators first.
That sounds like a lot of work (with the most enthusiastic volunteers likely being the most censorious) while doing little to stop someone who updates the content after it has been approved by the moderator.
For news stories, moderators can approve publishers (e.g. techcrunch.com) and then they don't need to review individual links anymore (though the ability to override this for individual links remains). Same for posts and authors.
If a post is edited to be something bad, there is still the fallback on reports and post-hoc moderation, making it not any more risky than having the local/federated timelines in the first place.
There's a finite number of publishers/authors that regularly create popular content, so the workload decreases after an initial burst.
Still not recommendation system instead of just chronological posts which makes it really impractical to browse when you follow more than 10 people. This is really where Mastodon could shine with open algorithms an end user could choose from instead of proprietary ones like Twitter and al.
Chronological home feed is our selling point. You can also opt-in to notifications when specific accounts post if you don't want to miss them (bell button on profiles). Finally, you can also split your home feed into lists. However, nothing precludes someone from developing a client that reorganizes your home feed somehow.
It does not have to be "this and nothing else". The main complaint people have with Twitter is censorship and algorithmic curation without transparency. Mastodon solves the first problem with decentralization, and it could just as well fix the second problem with a market for algorithms to apply to your own feeds. And you could still keep the default chronological timeline for those who wish to keep using it this way. Adding more features does not kill your product, it just makes it more flexible for more use cases.
I don't think I've ever seen a good recommendation system in practice (that is, having the properties of not accidentally hiding content I'd like to see AND maintaining the same level of reliability over time as my interests change), and I would imagine at least some segment of Mastodon's users would be escaping from platforms like Facebook that use them in part due to "curation exhaustion" - I would think that no recommendations is actually a very strong selling point.
People say Bytedance (Tiktok) has an excellent recommendation system, better at adjusting to interest changes than the other platforms.
Personally I always go out of my way to get the chronological view on twitter, but I have to say I am curious what an open algorithm could mean in practice...
As far as I know the experts say this is because the medium. Twitter has no idea what tweet you're eyeballing because there are 3-20 tweets on your view screen. Tiktok is very aware of what you stopped caring about, because it's no longer being viewed.
> I am curious what an open algorithm could mean in practice...
Could be a series of different algorithms to choose from, such as:
- a feed about the people you follow, ordered by the popularity of their posts among their own followers
- a feed about the people you follow, focusing on people who post least often and tend to be under-represented on a typical chronological timeline.
- an algorithm to suggest topics or other people to follow, based on other similar profiles to yours.
- a feed to focus on newer accounts instead of established accounts...
etc. the sky is the limit. You can then imagine a UI that goes with it to switch from one algorithm to the next so that you don't waste your time scrolling down.
No. I don't want curated shit or suggestions. I want my friends, as in the people I know, and the shit they say unweighted by a partial judge that i've never (and can never) meet. That's it. I don't want what an algo decides what their best of is, I just want to keep in touch with people I know. Most people I know would say the same.
And certainly people are capable of implementing algo-based clients. Heck, have them scrape your personal web and email and whatever activity, keeping it all local.
you dont get my point at all. if you follow lots of people you will end up being drown in whoever posts the most instead of stuff that you actually want to see. if you follow 2 people sure this would never be a problem for you.
I understand you, I just disagree. Maybe a conscious selection by user for post activity would be appropriate, but the current algorithmic solutions we see on mainstream platforms are trash. The default view of your 'friend feed' should be flat and unbiased.
It's not because you were never exposed to a good one that good ones don't exist. And the point I was making is that you could have several algorithms to choose from every time you are logged in - to focus on specific strengths of each sorting algorithm. Instead, following the chronology favors over-representation of the ones that post the most, which sucks completely.
Sure, if a PoC for a decent and transparent approach is released I will adapt this statement. Never did I claim that it can't be done. Until then, not so much.
I'm not a big fan of the common "it could work nicely if its just done well" in a world where nobody really does it well.
Agreed, this will just make the abusers-vs-algorithm arms race iterate faster, while commercial social media giants watch from distance and take notes, receiving valuable research for free. :)
Is Mastodon / the fediverse, the peak of composable asychronous communities (and IRC being the peak of synchronous communities)?
Just a question I thought of while staring. I really gave Mastodon a try for 6 months and microblogging was just not for me. I like the underlying technology though and feel it really has potential to creating an alternative to all other social networks and maybe even personal websites.
Congratulations! I remember when Mastodon was first posted to HN. It has become a really polished and thriving project since then.
I am a bit jaded about the whole Twitter model though. I haven't really found a nice twitter community, and I consider it mostly "write-only" TBH.
I wonder if there is an ActivityPub application that is more like the early Facebook or MySpace. Not so much centered around the feed, but around the profile page. You curate a really nice profile page, add info about you and selected posts. And it can also serve as a landing page for people who are not on the network. You can add people to "collect" them as friends and get updates and chat with them, but it is not about getting a feed with all their tweets. I think I saw a federated VK clone the other day, which goes a little bit in that direction.
I was wanting to host a Mastodon instance to use as a mail/chat/blog/publish/gallery service for myself, but based on an old (from 2017) official document(1) that I found, running a Mastodon instance doesn't come cheap.
Their new document stopped providing such information now. I wonder how things improved during the years, does it demands less RAM now?
Long story: my plan was to put the instance on one of my Raspberry Pi which got 2GB of RAM. But based on the old information, 2GB of hardware RAM is dangerously close to the limit, so I waited to see if things improves somehow (say Ruby suddenly become more memory efficient, I can dream too).
Try Pleroma. It will easily run on a raspberry Pi and is growing very fast. It's also a lot easier and simpler to install and deploy than Mastodon; it has far fewer dependencies. Also more features, like chat, have been around for years. Mastodon is falling behind even there.
I really recommend it. It was a much nicer experience for me.
I'm surprised to see the iOS app ship without a local/federated stream. The local stream especially seems central to the communities that are built with mastodon.
Yeah, this seems like trying to drive your users into a paradigm that is contrary to how people are actually using it. The central problem with any social network is discoverability, which is hard on a decentralized platform. For me, the process is/was finding an instance that was congruent to my interests, and the only way to determine that is by watching the instance timeline.
I'm admin for a small Mastodon server, and I'm kind of depressed that the official app is simply not going to support my local feed, that any feedback about this is ignored. The local feed is the main motivation to run a small Mastodon instance. I understand that it's useless to a huge server like the flagship instance, but I thought the point of the fediverse is to not simply run everything on a handful of huge websites.
Interesting thoughts from gargron. I can understand the desire to reduce confusion for end users even if I don't agree with the decision. I think the issue is with communicating what the local feee is. In my personal opinion the federated timeline is close to useless near instantly, but local is not.
Perhaps there really is no way to rebrand "local" to something users understand, but that feels a bit defeatist.
I think I would be more... ok with his statement if it was not the official app? If it was gargron's mastodon app, not "the" mastodon app. One represents the community, one represents his specific vision. But then again he is the majority driver of this product. But to not support large features of the main product in the flagship mobile app feels like a setback. _shrug_ sadly I don't use the product much anymore regardless so this is all just mental spewing at this point.
I'm terrible at reading usernames so didn't even realize it was you responding!
I read and reacted a bit to your thoughts on the previous GitHub issue around local feed in the app when someone posted it below. I can see the reasoning, even if I don't necessarily agree/it wasn't my use case.
Good luck with the project! I'm impressed with it regardless.
Back when I tried mastodon a couple years ago, the friction required to interact with users and content from other instances was incredibly annoying to the point of turning me off completely. Favoriting something should not take more than a single click regardless if it's from my instance or not. This doesn't appear to be addressed (was it already addressed in an earlier version?)
The friction you are describing is when you leave Mastodon's web app and go on the public pages of different servers (that have no way to know who you are because they are separate websites with separate cookies). You do not have to leave Mastodon's web app to interact with users and content from other servers. When you naturally see content or users from other servers in your home feed, on the explore tab, in notifications, and so on, there is no difference in how you interact with them. And if you need to look up something that isn't in the interface, you can use the search bar (you can paste URLs into it, too)
I use fosstodon.org. I don't know what version it has, but I can just click on any post's favourite button (or reply to it or boost it) even if it's from another instance. So I reckon if there was an issue before, it has been fixed or it's not universal to all deployments.
All that stuff works fine. I think what they are talking about is following a user on another instance which is still a little clunky sometimes just because of the inherent nature of the domain where you view their profile and click follow being a different domain to where your account resides.
I generally just search for the user and click follow on my instance to avoid the redirection steps.
The example image of the post is carefully done to make appear one side of the political spectrum worse than the other. I don't like this stuff. Specially if this people is aiming for an open place.
I was checking the UI, and started to notice some political keywords, like "MAGA" and others, and then I followed the thread just realizing it. Coincidence? Maybe, but…
I self-host a number of products for use between myself and a small group of friends. I like the idea of Mastodon, but due to its requirement of needing an email server, it's honestly more trouble than it's worth to try and host it myself.
If you are self-hosting for yourself, you can make-do without an e-mail server. You'd have to create an account from the command-line (`tootctl accounts create aquova --email=you-login-with@this --confirmed`) and turn on TOTP 2FA once you login for the first time to avoid e-mail based security challenges. For personal use, you won't need any other e-mails.
You could always go the barebones route and generate a mailto: link which contains all the info in the email that you usually send (in text mode of course) but which the admin can send from their personal account with their personal email client.
I am using a similar implementation in another fediverse project. Another example is/was AWS manual account creation.
You can self host pleroma, no email server required, it federates with activitypub so it's on the same network as mastodon and federates with it. I used to host a server a while back, it was pretty straightforward.
i think selective following is the future of moderation, mainly because nobody wants to look at sick crap all day long.
brings up the question of having to host the bad content though. this makes me think the client server model for decentralized networks is just dead in the water.
selective following + each user just holding their own data on the client = so many problems solved
Have a look a the decentralised projects put there then. Ssb (secure scuttlebutt) seem to fit your description, but fair warning: this setup comes with its own set of problems around moderation and other things.
But as you alluded to, I won’t use it until a few new features are developed like “strong” follows vs “soft” (doesn’t automatically seed all of their follower content) follows.
I disagree, client/server where there are multiple servers is the future - for legal reasons and for social reasons. It allows you to handle all sorts of governance issues...
1. If the EU passes some crazy law, you can just host the server in the EU and peer only with EU servers and EU customers so everyone complies with regulation.
2. If you don't like the mod rules, you can change servers and find new policies/rules. That is what we're seeing with many "conservatives" who feel that big tech is "biased".
3. Inevitably, people who create bad content ("sick crap" as you say) will be blocked and forced migrate to low-moderation fringe servers (or stop using the system if none exist). Very popular servers will increase their KYC type policies to cut down on moderation needs (and use moderation as a selling point). Sketchy servers won't be allowed as peers to common servers, or will come with warnings, just like how gmail flags many self hosted email servers as spam and corporate email servers flag everything from external domains.
4. Today, email is the only common protocol that isn't centrally owned besides phone systems for people to communicate. Zoom had a good boom during the pandemic but because its centralized it won't stay as a viable compatibility tool between organizations. As the costs rise on using centralized products (compliance, etc), then turning to self-hosted with inter-op will be more popular. Maybe those businesses don't care about a Twitter clone, but federation lets orgs own their communication (eg. monitor traffic, add retention policy, etc) but operate beyond their borders.
What is the incentive for a server operator to take on all this risk?
Most of these people running servers don’t charge anything, so I can only assume that it is a (1) a hobby or (2) they have bad intentions.
If 1, they have failed to understand the dangerous legal position they are putting themselves in.
If 2, they are wonderfully set up to entrap or just monitor people and send info to the authorities. Maybe that in itself is a fun hobby for them, who knows?
Every single point you bring up here is completely unnecessary work. It’s just a lot of work.
Why would I find a server with exactly the policies i prefer when I can just self-moderate and follow the people i want to follow?
Not to mention that these “policies” are basically written on a napkin and at the whims of a random person who may have gotten bad indigestion that morning. My question is simply why bother with all this needless bureaucracy when you can be left alone?
If it’s a hobby, then that’s fine. Those servers will be like hobby email servers today.
Why can’t they have good intentions? Eg a real business. Like Gmail, Outlook, etc before them. Only for modern day services. Why does anyone host anything on the internet? What is this, 1985? People will host and share things online for others.
Why would someone who hosts something have to be a nefarious covert LEO?
You’d find a server because self moderation is a lot of work. People already seek out specific people to follow and that’s more than enough moderation for them. The rise of algorithmic feeds being popular is because self moderation is already not something people want. Who wants to host the data of their feeds locally and have to query other individuals? People want always available servers not p2p. We see the behavior already.
“Why… When you can be left alone” is probably the attitude of someone not meant for social media.
> Those servers will be like hobby email servers today.
Nobody relies on these for real communication. Maybe as a toy. But everyone would have a gmail as backup.
> Eg a real business. Like Gmail, Outlook
If it’s a for-profit business, that does change things. But please let me know of any business you know of like this that isn’t spying on you, isn’t selling your data, and is still reliable. I can’t think of any.
Actually to lower the bar, let me know of any mastodon server that is run like a legitimate business that a user could potentially sue for breaking contract.
> self moderation is a lot of work
Not in my experience. Simply don’t follow people that you don’t want to follow.
> People want always available servers not p2p
Always-available is not mutually exclusive with p2p. see: relay servers. I don’t need to rent my account from a relay server, they can just seed my data for me. Heck they don’t even need to be able to read my data to seed it for me.
> “Why… When you can be left alone” is probably the attitude of someone not meant for social media.
And not being able to see possibilities beyond the fediverse (a completely failed project from adoption and UX standpoints) is not an attitude meant for hacker news. Innovwtion should not stop just because some techy hacker people have made a solution. We shouldn’t be precious about these things just because we see the builders as one of our own or something.
Isn't that kind of the point of open source software? I doubt they would use it going forward because of the BS the mastodon developers already tried to pull on a closed alpha site because they disagreed with the users. I get it, there's some people you let the little things slide because you like them and others you act strict as hell because you don't like them. It's odd to use an open source software when you feel the developers are actively trying to catch you slip up to bring you down permanently.
That's completely besides the point of what I was getting at. They put out press releases and pitch decks boasting on how they were going to develop the best social network that the world had ever seen.
Look at the laughable "Infrastructure" slides on their investment deck:
And all this bluster just to pay someone in Eastern Europe to re-skin an existing open source project. It should take about a week to recreate what they've done. It's like saying you're going to make the #1 Slack competitor then just re-skinning Mattermost. It's pathetic.
I love open source and all the ways it benefits the world. But I hate exaggerated bravado when the actual service is the very definition of average.
> Isn't that kind of the point of open source software?
With free software, yes. It also includes undesirables as well.
> It's odd to use an open source software when you feel the developers are actively trying to catch you slip up to bring you down permanently.
Well it seems that the Mastodon developers have forgotten that there aren't any restrictions in free software except for the terms of the license and in the end Truth Social complied. So that is that.
Putting special source code restrictions on other users beyond the AGPL intends to basically defeats the purpose of free software.
Clone, as in a re-skinned version. But my main point is the irony of releasing a pitch deck like this [1], and just adding some custom CSS to popular open source product.
That's not how this works. Mastodon has an AGPL license on their repo. The burden is on you to read and follow the license. If your devs don't tell you they were illegally ripping code then you need better devs. The burden still falls on you.
If a vendor creating IP/code for your company violates a license, your company violates the license. It can even be as simple as a contractor using an image that they don't have a license for. If they upload the image on your website/use it anywhere public, you are liable. Recently had a client that had to pay out $30k because one of their contractors did exactly that.
This is very basic stuff and makes me wonder if you've ever worked in a vendor/client relationship before.
I'm not defending the company, I'm applying Hanlon's razor to the situation involving the GPL licensing.
I'm not an investor in the company nor do I have any interest to invest. I just think you guys were being biased in assuming malice as well as blowing it out of proportion.
Your bias is due to your hatred of Trump and everything he touches. That's why you were so aggressive in your critiques against even the developers Trump's company employed.
Me not picking up a pitchfork in your witch hunt is not me being biased, it's you being a lunatic...
The license is very clearly included in the code they originally stole and tried to pass off as their own. This wasn't a short timeline as they'd been including it in investment decks for quite some time before release. This is super basic copyright and licensing stuff. And something that a legitimate company with nearly a billion dollars in funding should know.
Given that they want to be taken seriously as a major social media network and public company, you'd think they'd actually do some development of their own rather than just copying another project.
They hired a North Macedonian development group to create a a cheap copy of the Mastodon code and tried to remove all logos & mentions of Mastodon in the source code.
It'd be like announcing that you're creating what will be the world's most popular website builder and blogging platform, then spending 10k to just rip off WordPress and thinking job done. It's hilariously inept.
The more hilarious thing is that, Parler did actually just use Wordpress to make their "new" social network! It ran hilariously slow up to the point that it ramped up their server costs, and eventually led to someone hacking the whole thing via a Wordpress vulnerability (hence terabytes of private data getting leaked all over the place).
Way to keep jobs in the USA, I guess? But perhaps this was a 4d-chess move to stay outside of the influence of US/western 'big tech' which 'silences' right wing Truth? Who can tell?
More like them only wanting to spend 5 days worth of a single outsourced coder's time. I can't imagine changing some CSS and find/replace "Mastodon" in the source code took much longer than that.
Just look at the "Infrastructure" slide (22) in their deck I posted above. It's like a middle schooler did a book report on web development.
Of course not. They probably just wanted to pay a laughably small amount to make a clone of Twitter. And whether the client asked for it to be done or not, the outsourced development group they hired copied the source code while removing the required attribution.
They didn't release the source code as required by AGPL and pretended to have built it from scratch initially and defederated from the rest of the network.
That's them acknowledging that they haven't built anything novel or interesting, the just copy/pasted another project and expect people to take them seriously as a major social network.
So their iOS app is also copy and pasted project then? Another asset that didn't stop them from launching, did it?
On top of that, so basing on 'free and open source software' and even giving attribution now means 'you haven't built anything novel or interesting'. Oh dear.
> the just copy/pasted another project and expect people to take them seriously as a major social network.
Yeah, surely Mastodon by itself has hundreds of millions of users worldwide since launch day right? /s
I never knew that a controlled launch, only in the US with a waitlist already means 'it is over' or 'it is failing' /s I guess it depends on the 'sources' one reads.
It's bizarre and hilarious to me how much you're defending a company that has raised $1 billion dollars promising to create one of the greatest social networks on earth - yet the core of their product is a re-skinned open source project (that originally violated the license) and their execution has been incredibly sloppy (wait lists that people have been on for months, 404 error pages when people link publicly to their profiles).
If this company did not have their current political affiliations, I seriously doubt you'd be defending them for a second. Because all the evidence of how well they are performing points to them being laughably inept.
I don't actually care about them. I'm just asking basic questions to you which it seems that you are still struggling to answer them. You also seem to be unable to ignore them and have a strange obsession following them for some reason because it's the Orange Man again isn't it?
Mastodon, despite being an 'alternative' hardly anyone cared about it.
Not even the general public cared either for 6 years until Team Orange came along and used it. They'll probably surpass the amount of users on Mastodon regardless away.
> If this company did not have their current political affiliations, I seriously doubt you'd be defending them for a second. Because all the evidence of how well they are performing points to them being laughably inept.
So now you are a fortune teller and somehow 'launch day disasters' are indicative of future performance isn't it?
Why does that even annoy you? Perhaps, former and twice impeached orange man 'Donald J. Trump'? is less triggering to you and makes you feel better about yourself?
Who cares?
You haven't answered any of my questions have you? Only still obsessed around the orange man.
They put out press releases and pitch decks boasting on how they were going to develop the best social network that the world had ever seen. They have investment slides citing their technical team, who supposedly came up with laughably vague "Infrastructure" slides:
And all this bluster just to outsource the re-skinning of an existing open source project. Vlad N listed as their CIO on slide 21 is Vladimir Novachki, CTO of Cosmic Development, a North Macedonian outsourcing firm. It would take about a week to recreate what they've done, costing about $5k max.
It's like saying you're going to make the #1 website builder then paying someone $5k to just re-skin WordPress. Given the promotional materials they've put out, it's beyond pathetic.
Adding the editing of posts is a good feature addition, in my opinion. I wonder if posts that have been edited display that they've been edited, though.
> "The original and previous versions of the posts are saved and remain accessible through a history view. And people who have previously shared the post get notified about any edits, so they can un-share if there’s foul play."
It sounds like they've thought about these risks, and I would assume that the UI element for accessing the "history view" looks different if there is no history, i.e. the current version is the only version.
That would cause havoc; specifically because other instances can forward your message. So the original message will always float around in retweets and replies. It'll probably be very visible.
The discovery problem can be handled pretty straightforwardly: if you want notifications of replies to your posts, then that's just another feed that you subscribe to—a separate service. You don't exactly need an always-on "instance" providing an inbox endpoint to relay notifications to you.
You give up private channels (DMs), but you gain a lot more flexibility. It's a shame that there are so few server (and client) implementations for "the fediverse". We should have at least half as many options as we have in static site generators themselves. (In fact, with this approach, your preferred static site generator could become part of your "client"...)
Imagine your corner of the fediverse being reachable at $YOURNAME.github.io.
Prior art: Fritter <https://github.com/beakerbrowser/fritter>