Like, everyone outside of Mastodon must issue a #CW if they use
bold type
italics
a code block
a bullet-point list
or anything like that because it irritates those who are still used to the #Fediverse only being old-school Mastodon. You know, just like #LongPosts with over #500Characters.
Re: Themes for Hubzilla or Streams. (TLDR at bottom.)
Trying to create a theme and advanced UI features without creating modules or addons has been an interesting journey. Hubzilla, and I assume Streams, has hidden undocumented features that are not used by Redbasic. This reduces some of my work, in some cases, but it is also challenging since all of this is undocumented.
For example, apparently Hubzilla allows you to paginate and sort many different types of content and lists. The Redbasic theme does not use this code, but it's there in the core. That means I don't have to create a module with that functionality... once I figure out how it works in the core.
On the other hand, I discovered that certain functionality, such as marking a post as seen, requires JavaScript that is directly tied to how Redbasic works, so if I change how the theme is structured, that JavaScript stops working. This is a nightmare to deal with, since I either have to conform to how Redbasic does things, or I have to rewrite all of that JavaScript functionality to work with the new theme.
I am not a JavaScript developer, so I will have to hire someone to do that part of the theme. Or figure out some other way to handle that functionality. As a result, my first official theme will be Redbasic with a makeover instead of the total redesign I want to make.
A lot of interesting discoveries like that.
I am trying to make it so that my UI enhancements do not require modules or addons. And when I do have to make modules and addons, I am trying to design them in a way that does not conflict with the core. But this is very very challenging.
In some cases, I have had to ask for changes to the Hubzilla core so that certain aspects of my themes will work. Typically small things like adding a variable to a core module so that it can be accessed in a theme. And Mario has graciously added those for me. But other than simple stuff like that, I would have to be very convincing on why it would need to be added to the core.
For major changes, I would either have to make addons or modules. And there is no official way of installing a module other than to upload it to the SiteModule folder. If I wanted to install it via git, I would need to add my repository and then merge my code with the core code. I am told this is frowned upon, but it would work. But it is my understanding that this is how some specialized web hosts handle installing Hubzilla with their own modifications.
For specific purpose builds, like an e-learning website, I will just outright fork Streams or Hubzilla. It is just easier to include the necessary pieces that way,
I am also working with specialty web hosts so that when they install Hubzilla, they install Neuhub with it automatically. So even though Neuhub won't be part of the core, Neuhub will be distributed with it in many cases.
So, that is the state of things right now.
TLDR; I can retheme Hubzilla and Streams without using modules or addons, but advanced functionality will probably need an addon, module, or a fork. And, eventually, if you use a specialty web host, Neuhub will be bundled with Hubzilla or Streams.
we are all hoping for your efforts @Scott M. Stolz - hope you can keep things in sync with the core code... the best would be that your work would get part of the core code - think about that
streams is definitely more advanced concerning ActivityStreams and ActivityPub - it is lightweight and has all you need if you "just" care about posting in a network... it is still not that easy to handel as other fedi apps because of permissions and so on..
For me also the UX / UI of Hubzilla which got a lot of improvements by @Mario Vavti and the dev team is more appealing - the /hq and the /pdledit_gui page are just two examples
if we care not just about connectivity to other Fedi Apps but also for the philosophy that all your different Net/Web - data should be at one spot in your hands like the Indiweb demands, Hubzilla still is the one system which offers the most under one hut.
i strongly wish that the HZ dev team can port the improvements made by steams to Hz as well... that is what they said they want to do... this may not be possible in all parts but e.g. OCAP is now also part of HZ... thank you so much for that.
hope strongly hat HZ and streams stay close, not in competition but by supplement
the best would be that your work would get part of the core code - think about that
Won't happen.
Anything that's accepted into core is something more that Mike has to take care of whenever he changes something. And we've seen on Hubzilla what happens when you leave the core devs with a bunch of UIs that have to stay in sync with the backend: The simple default one that's a leftover from 2012 was kept working because Hubzilla needed one working UI. The rest withered away until it had become too incompatible to use. Even then, they stayed in Hubzilla because nobody even took care of throwing them out until fairly recently.
The best that could happen would be a third-party repository run by Scott being accepted as "semi-official" and included into default installs.
For me it is all about a vision of a ethical kind of social media.
I'm not a coder at all but i had contact to quid a few DEVs here in the past years. It comes down to me that they mostly lake of real visions but that they want to reproduce known things here in a decentralized network structure. They like to concentrate on their own projects but don't have the vision of the whole thing...
e.g. even the most experienced coder don't get that something like OWA is needed here... since @Pascal (Hubzilla) proved that implementations can be done quid easy the function is still not adopted by other projects - WHY?
Because they don't see the need of a permission system and without a permission system OWA can't really work on their projects.... so the one thing needs the other thing... it all fits together here at HZ and Streams...
The lack of vision and understanding is also among net activists who are fighting for all kinds of digital freedoms. Some say that thy don't know about HZ and streams .. I know for sure - that is just NOT true at all ... it is not because the information is not there... it is just because they have NO vision but want the same as META&CO has done but just decentralized....details don't count.
That said - the ability and willingness of a "regular social media user" to do things different as they got used to can't be underestimated by us who are willing to explore things here since years.
We can come up with all kind of philosophies why this is this way, but this circumstances are facts.
I see still a long way to go... but a clear future. After all it just takes much more time as we like to think.
I'm not a coder at all but i had contact to quid a few DEVs here in the past years. It comes down to me that they mostly lake of real visions but that they want to reproduce known things here in a decentralized network structure. They like to concentrate on their own projects but don't have the vision of the whole thing...
e.g. even the most experienced coder don't get that something like OWA is needed here... since @Pascal (Hubzilla) proved that implementations can be done quid easy the function is still not adopted by other projects - WHY?
That's because everyone only ever wants to clone "centralised corporate social silo XYZ" in the Fediverse. That seems to be all they know. And it seems rather risk-free.
It seems risk-free because, sadly, it's exactly what most Fediverse users want: Twitter without Musk and Nazis. Reddit without greed and dictatorship. Instagram with privacy and without rampant cross-platform spying. But otherwise the same. That's exactly why so many Mastodon users are waiting for their salvation in the shape of a Bluesky invite: Bluesky is being advertised to them as "now really literally Twitter without Musk and otherwise exactly like Twitter".
It's hard to get people interested in projects that aren't more or less straight clones of anything they already know. And (streams) isn't like any corporate silo.
Also, I guess it's a question of ego. Many devs want to have projects all of their own, not rarely for fame. That might be why so many Fediverse projects were abandoned on the way: The devs discovered that having their own scratch-made projects means a whole lot of coding and testing and responsibility and whatnot, not to mention convincing people of using your stuff which means to ideally get it sufficiently stable first. Their primary motivation isn't to make a change. If it were, they could achieve a whole lot more by contributing to other, bigger projects. Although (streams) isn't even really a project.
As for single sign-on, centralised corporate solos don't like the concept unless it's them who control that single sign-on system, and everything else is only a client. Thus, none of them offers single sign-on because Meta doesn't want the identities of Facebook or Instagram users to be handled by Google or Apple, and nobody else would use a single sign-on system controlled by Meta. Thus, nobody has ever used single sign-on on social websites. And thus, nobody has an idea of how that could be useful.
OpenWebAuth doesn't seem any different because if you explain what it is and where it comes from, it looks like Mike/Hubzilla controls it. Which is non-sense because it has little to do with Hubzilla, Hubzilla itself took a while and a whole lot of work to introduce it when Zap & Co. were happily using it already, and Mike had little to nothing to do with Hubzilla at that point.
Because they don't see the need of a permission system and without a permission system OWA can't really work on their projects.... so the one thing needs the other thing... it all fits together here at HZ and Streams...
That's another issue: People on ActivityPub-based Fediverse projects, Mastodon first and foremost, don't want permission systems. At least not on Hubzilla's and (streams)' level. They'd make things too complicated.
Much like Windows Vista got too complicated because it finally killed the "consumer Windows" line without a permission system, last seen on Windows XP Home, and forced Windows NT-style permissions upon everyone.
The lack of vision and understanding is also among net activists who are fighting for all kinds of digital freedoms. Some say that thy don't know about HZ and streams .. I know for sure - that is just NOT true at all ... it is not because the information is not there... it is just because they have NO vision but want the same as META&CO has done but just decentralized....details don't count.
@Scott M. Stolz, take a note: Hubzilla and (streams) need to go back to where Friendika was in 2011. And mimic everyone else's UIs so at least they look like they're cloning something.
I'm not kidding, Friendika cloned Diaspora*'s UI before Google did it.
take a note: Hubzilla and (streams) need to go back to where Friendika was in 2011. And mimic everyone else's UIs so at least they look like they're cloning something.
I wouldn't say mimic, but rather take the best most familiar pieces and incorporate that.
But I get what you're saying. That's why I want to add things like an inbox for DMs, forums that actually look like forums, blogs that look like a blog, etc.
Mike's been developing this a long time. I have been using his software since Friendica/ka days.
Mastodon used to have hella porn and call girl. Maybe it still does? I dont use it and don't program in Ruby. They do have good documentation esp implementation of ActivityPub
Ideally, there'd be loads of people developing add-ons for (streams) so that those who run instances can throw together whatever they need. (streams) already outshines most Fediverse projects as it is, vanilla.
The problem might simply be that people don't know it exists, and if not, it takes them too long to learn about it because it's "too far away from Mastodon". Especially aspiring or actual Fediverse developers.
For example, there are those who arrive on Mastodon, get totally giddy about how great it is in comparison to the centralised corporate silos and start developing cool new Fediverse stuff. Only that they build it hard against Mastodon and only Mastodon because they don't know yet at this point that anything else exists out there. And then users come and ask them if they could add support for, what, Akkoma or Firefish, and they might ask the users back what Akkoma or Firefish even is. Not to mention their reaction if someone tells them there's a thing called Friendica that's connected to Mastodon, but much more powerful than Mastodon and almost six years older than Mastodon.
And then there are those who develop all-new Fediverse server software from scratch. Maybe even yet another micro-blogging project because they want one or two extra features that whatever micro-blogging projects in the Fediverse they already know about don't offer.
Even if the latter started working on something that isn't micro-blogging, it'd be much less of an effort to develop it as an add-on for (streams) than to develop it as a brand-new ActivityPub-based stand-alone project. And the outcome would be both more powerful and more resilient. But they don't.
Maybe it's simply because they never learn about (streams). Or when they learn about it, they've already got a beta or stable release out, and there's no way back.
Or maybe they want to stay as close to Mastodon as possible because "that's what everyone uses". And they can't imagine that something that uses ActivityPub as an add-on with two killswitches (admin-side, user-side) could possibly be as "close to Mastodon" as any scratch-built ActivityPub project. Then again, maybe their idea of "close to Mastodon" is to largely ignore the W3C ActivityPub spec as if it didn't even exist and completely go by Mastodon's implementation.
I don't know how to raise more awareness for (streams). More public instances could help, and its availability for Yunohost could be step into that direction. The lack of instance listings shouldn't be much of an obstacle; I guess even many Mastodon users pick their new home instances by coming across them on a timeline rather than seeing them on a list. Maybe Scott can adapt NeuHub to (streams), so it becomes another great deal easier to use.
(streams) can only thrive on word-of-mouth, more than any other Fediverse project. So what we need is mouths to talk about it, especially from a user's point of view.
Jupiter Rowland wrote:> "Ideally, there'd be loads of people developing add-ons for (streams) so that those who run instances can throw together whatever they need."
That would be good. I hope people will create more add-ons than forks. That's how WordPress became so useful: you can build zillions of different sorts of website from WordPress, but the core software remains the same.
Jupiter Rowland wrote:> "(streams) can only thrive on word-of-mouth, more than any other Fediverse project. So what we need is mouths to talk about it, especially from a user's point of view."
I sort-of agree, but I don't know whether this is the right way to be thinking about it. We don't really care whether (streams) thrives, we care whether the users thrive. We believe (streams) is a really good tool to help users get what they need and want -- they just don't know it.
It's a subtle difference: help (streams) acquire more users, vs help users by bringing them to (streams).
We don't really care whether (streams) thrives, we care whether the users thrive. We believe (streams) is a really good tool to help users get what they need and want -- they just don't know it.
It's a subtle difference: help (streams) acquire more users, vs help users by bringing them to (streams).
The motivation is different, but the means would largely be the same, and the outcome would be the same, too: more people using (streams) and thus talking about (streams) to, for example, Mastodon users.
They would learn about a Fediverse software that not only offers them easy and complete moving between instances, single sign-on, full-text search, quotes, text formatting and a higher character count, all of which are or were on the wishlist of many Mastodon users, but also resilience against instances shutting down in the shape of nomadic identity. All without piling all kinds of stuff upon them that they'll never need. Even if all that is optional on Hubzilla, it still clutters the apps list. And they'd still get goodies like an online file storage and a CalDAV and CardDAV server. Granted, the latter don't have frontends, but CardDAV doesn't have a frontend on Hubzilla either, and the calendar frontend is so far from the bee's knees that I remote-control it from Thunderbird, so you can do without it.
Okay, you won't get those who want old Twitter back, who use Mastodon as if they were still on Twitter and who are now waiting impatiently for their Bluesky invite. You won't get the Mastodon fanbois and fangurls either who are convinced that only Mastodon can be the be-all, end-all of decentralised social networking or those who want everything that isn't Mastodon be purged from the Fediverse.
But you'd get the geeks. The tech-curious. Those who find all commercial social walled gardens lacking and Mastodon as well. Those who are ready to jump to Firefish or Friendica because they think that is the be-all, end-all. Because they haven't heard of (streams) yet.
Fact is that there are only four Fediverse projects that grow on something else than word of mouth within the Fediverse: Mastodon, Misskey, Lemmy and /kbin. All three are destinations of migration waves from commercial walled gardens, and in Misskey's case, this is even limited to Japan. The others have lately recruited almost all new users from Mastodon or other Fediverse projects. I dare say that even most Pixelfed users come in from Mastodon and not from Instagram. So it's Mastodon and the rest of the Fediverse where (streams) needs publicity.
The first to lure over are those who are willing to run their own public instances. Instead of launching yet another Mastodon instance, they could just as well launch a (streams) instance which even has the advantage of running on a run-of-the-mill LAMP stack and doesn't require Ruby on Rails. Next would be users who can then talk about how (streams) is different from Mastodon from their personal point of view and recommend (streams) to others who are looking for something that doesn't have Mastodon's limitations.
This is also important because due to how obscure (streams) is, the only nomadic Fediverse project that's halfway known is Hubzilla. And Hubzilla is hardly newbie-friendly. In fact, as it is now, it isn't friendly to anyone but the most hard-core geeks. But there are still people coming from Mastodon and trying out Hubzilla. This is so big a step that it's likely to fail. And then these people are burned and won't touch (streams) if it sounds like "Hubzilla light" to them.
Still, you're right in that the motivation for getting new users to (streams) must not appear to be, "(streams) needs more users!1!!" It must be, "If you want this and that feature on Mastodon, (streams) has it and a little bit more."
In this regard, it actually makes sense to slim (streams) down. That way, there isn't much to remove or re-write if someone wants to turn (streams) into their own project.
I have a problem with that statement and I'll tell you why. Maybe I got it wrong.
I'm actually assuming that with a bit of communication, even a diverse assemblage of techno-anarchists can actually figure out how to put aside their differences and work together for the common good. Implicit in your comment is that this is never gonna' happen.
And so far - you're right and I'm wrong. I guess I'll just have to crawl back into my nowhere land and keep making all my nowhere plans for nobody.
I think you've set things up so it can go both ways simultaneously (working together and forking off separately). I believe that's a good thing, because it lets people collaborate, and also lets them take off in their own wild direction. Who knows what they'll come up with? And if people have different visions for what they want to build, that doesn't preclude collaboration and merging of different developers' code.
I'm actually assuming that with a bit of communication, even a diverse assemblage of techno-anarchists can actually figure out how to put aside their differences and work together for the common good.
I think it will take more than communication. It will also take some coordination and collaboration. We all have different skills and if we want this technology to propagate, it has to go beyond a bunch of one person islands doing only whatever they want. Different people can bring things to the table. We basically need to federate, just like our projects. Independent actors with aligned missions.
I do believe that communication is vital. So is making it easy to collaborate. But we still need to build that part.
And, probably most importantly. we have to figure out a way to work together, while still allowing everyone to be the captain of their own ships. That is the tricky part, but I think it can be done. Enlightened self-interest at work.
And I should probably add some historical perspective so that there are no mis-understandings. Friendica and Hubzilla both ended up requiring nearly a complete re-write to evolve further. But they had both attracted passionate developers and communities who didn't want to follow me on my own evolutionary journey. This happens and it happened. I basically fired myself from those projects and abandoned them, and created a fork for my updates in order to keep those communities intact.
This is and was highly disruptive and I've learned a lot from those mistakes. If you disagree with the direction I'm taking, you'll have to fork. I'm not doing it again. But I'm also not creating a community this time. I contribute to this repository. I will hopefully contribute to it until I finally pass form this earth. My only involvement is to contribute to this space and help move it in the direction I feel it needs to go. I have a few strong opinions, but I tolerate other approaches and opinions and try to come up with win-win solutions that work for everybody involved. I'm not creating a project or product. If these things interest you, then you do them - and create your own space if you feel I'm doing everything wrong. Or you can stay here and add stuff to the public domain and for the common good as I'm doing -- so everybody benefits and so we're not all moving in completely different directions. I don't know how this kind of structure will work because I've never done it before. I only know what didn't work and I'm trying not to make the same mistakes again.
I am sure @Mike Macgirvin (dev) can clarify further, but my impression was that Streams was going back to basics, with the focus solely on the fediverse server aspect of the project, whereas Hubzilla is both a fediverse server and a CMS, among other things.
As such, the core of Streams will always be lean, and focused on being a fediverse server only. If you want to add something that is not related to that goal, you would have to build your own addons, since anything out of scope won't be included in the core.
You pick Streams if:
You want a lean fediverse server without the fluff, with bleeding edge fediverse technology.
You want to build something on top of it, so you fork it or create addons for it.
You pick Hubzilla if:- You want a fediverse server with a suite of apps built in, with an older, but possibly more stable Zot6 protocol (*stable from a feature standpoint).
At least that is what I have picked up from listening to Mike, Mario, and others discuss the nature of their projects.
Thing is, I've read somewhere that all connections save for Zot6, Nomad and ActivityPub were thrown out of (streams) because they stood in the way of Nomad working properly. That this was the reason to even throw out the RSS aggregator. That ActivityPub is the only non-nomadic protocol still supported by Nomad.
I've understood it in such a way that due to how Nomad was designed, namely with a focus on ActivityPub which required sacrificing any and all compatibility with anything else, nothing based on (streams) would ever be able to connect to Diaspora* or OStatus or RSS or Atom or e-mail or XMLRPC again because even writing new unofficial apps for that had become impossible.
Like in 2018 when it looked like brand-new Zot6 would never be able to connect to anything non-nomadic. That was when Zap only spoke Zot6, it might have been compatible with Hubzilla in some way, and Osada did still speak ActivityPub next to Zot, but it wasn't nomadic.
But now I guess it was just a case of throwing these connectors out to slim the official parts of (streams) and their further development down.
@Jupiter Rowland What effects could that have, what you describe about Zot12s development. Is this just ging to isolate itself completely, or is there potential to open up widely?
@_jayrope From what I've understood now, the only reasons why all the other connecters were thrown out are:
To slim (streams) down. To make it the bare-bone it was intended to be.
So that Mike doesn't have to touch every last connector app whenever he changes something in the core. Because practical experience has shown that no-one else would.
So in theory, it's still possible for (streams) to connect to Diaspora*, for example, in the future. Mike has thrown out the Diaspora* connector, and he won't accept a new Diaspora* connector into the streams-addons master anymore. But everyone may feel free to write a new Diaspora* connector or port Hubzilla's Diaspora* connector app, just as long as they keep it fully third-party and on their own repository, and it's them who maintain it.
It's still possible. It's just that Mike doesn't want to deal with it anymore. And he knows that if it's in streams master or streams-addons master, it's him who'll have to do all the work. That's why it'll have to be third-party in the future.
@_jayrope (streams) is officially maintained by the community. With a little help from Mike.
But since the community hardly does anything, it's Mike who ends up doing everything. That's why he's so involved.
As for future addons: You won't have to fork (streams) for that. I'm pretty sure that (streams) supports third-party repositories for add-ons, themes etc. just like Hubzilla does.
So basically, you install (streams) from the streams repository plus the extra apps from the streams-addons repository. Then you add a third-party app repository or two or six. And from there, you can install a future Diaspora* connector or RSS aggregator or whatever.
@Jupiter Rowland @Bill Statler How "easy" is it to get involved into Streams development? Is there a working e.g. up-to-date documentation? Who decides on, which propsed new features will be allowed? Can i find in-depth insight to understand the structure and making of this?
Nobody is in charge, but Mike controls what gets into the Streams repository on Codeberg. Anyone can make their own repository for add-ons -- I think Waitman Gobble is working on one. And anyone can make a fork if they want to make major changes or they disagree with Mike's decisions.
There is some technical documentation in the repository, in the form of "*.md" files in several different folders. When I have some time, I'll make a "Table of Contents" for those files.
Streams isn't a project or product with goals and directions and target markets. It's a public domain code repository which can do some really cool stuff; and creates a relatively safe but vast online space where instance boundaries vanish.
Completely unlike any other online space or project in the fediverse, except perhaps its predecessor -- which was widely ridiculed for its complexity.
It is maintained and driven in a completely ad-hoc manner by a very loose-knit assemblage of (primarily) techno-anarchists, each with their own skills and motivations; but who ultimately despise authority and just want stuff to work.
It is maintained and driven in a completely ad-hoc manner by a very loose-knit assemblage of (primarily) techno-anarchists, each with their own skills and motivations; but who ultimately despise authority and just want stuff to work.
This is why, I think, a top down organization, or even a grassroots organization, would never work for the fediverse.
Voluntary cooperation and collaboration, yes. With everyone participating being autonomous and independent, definitely. After all, one of the main points of the fediverse are freedom, independence, and privacy.
Attempting to get everyone on the same page is like herding cats. It's not going to happen.
We can promote cooperation. We can make it easy to collaborate. We can even give incentives to collaborate. But, in the end, everyone is a free agent. They get to do what they want.
Of course a git allows to do that. But i see no bundling of forces rather than dispersion. Are you aware of any?
I am hoping to be a unifying force, at least to some degree. But instead of trying to heard cats, I will just put out some milk, and see who comes to the table.
My goal is to encourage projects to work together and be compatible with each other. Not just Hubzilla and Streams, but any project that wants to utilize OpenWebAuth and nomadic identity.
But instead of using a top-down structure where we issue directives, we will create an environment where it is in the best interest of fediverse platforms to collaborate with each other. Basically use what philosophers call "enlightened self-interest" as a unifying force.
For example, one initiate that I will be promoting is Magic Sign On, which is basically another name for OpenWebAuth. We want to recruit new identity providers and add more websites that allow Sign On with Magic Sign On,
I have many other initiates planned, and once I release the Neuhub Tab theme, I will launch several websites that explain what I am up to and how people can participate.
I am hoping to set up a public benefit corporation (PBC) to manage this, and if people are still interested in forming a Hubzilla Association, help build that too.
But I can't do all of this alone, so, when the time comes, I will be asking for people to join me on this journey.
There's a sort of table of contents if you visit /help via the help app or just type a question mark into the search bar. If you want to find documentation related to a particular topic, type ?topic into the search bar.
Develop is for technical documentation
Guide is useful information for users/members and administrators
Site is for if you want to provide additional resources or customise the guide for your own site users
"There's a sort of table of contents if you visit /help via the help app..."
I was thinking more about the various .md files scattered around in other directories. For example, you recently added spec with a bunch of specifications for Nomad etc.
For my own convenience, I made a few links in doc/site/en/ like:
Ultimately I decide who has repository access. I would like to add other repository maintainers - especially in other timezones so there isn't a bottleneck or delay for fixing breaking changes whilst I'm asleep in Australia. I've given access to @ray peaslee, although he's been quiet lately - after he had done considerable work on a feature that was later rejected. This is unfortunate.
If you want to add a new feature, I would highly encourage you to join the streams group and bring up your idea or initiative and we can discuss it in the open. Would prefer this happened so as to learn about prior art and why things were done a certain way. Then your work is unlikely to be rejected. We're open to nearly any change (seriously), but if I have a problem with it, I generally ask that you put it behind a feature toggle or make it an addon. Basically anything that changes existing behaviour and/or which we cannot arrive at consensus on which approach is best or should be the default.
Documentation goes stale. Always. That's why there isn't enough at the moment. I had to toss the original hubzilla documentation because very little of it is correct any more and even less applies to streams. Though consulting it can often provide valuable insights and guidance. I encourage folks to create more documentation, and just post it to the group if you lack ability to deal with repositories and code. All members should have search access to the group. If not, let me know. We just moved to a new site and I haven't checked all the settings.
The code is the ultimate documentation. This is how it works - the good, the bad, and the ugly. There is plenty of all of these because this codebase ultimately goes back over 20 years and has been touched by a lot of people (see the CONTRIBUTORS file, but which only goes back 13 years - prior to that it was on other version control systems and the contributor information is now lost to time). There are a lot of code comments. Maybe not enough, but should explain why a particular logic path was chosen and trouble spots are usually highlighted.
@Bill Statler Okay, well, i am looking at Friendica, where he does or did a lot of work, too, but there is also a small community of other devs, it seems?
Mike created Friendica and Hubzilla, but as far as I know, he is not actively working on either one today, and other developers have taken over both projects.
Since I brought up Zot12, I should probably clarify that there is no such thing as Zot12.
We have Zot6, which is the latest stable version of the Zot protocol used by Hubzilla, Streams, and their forks. Streams uses Zot6 to talk to Hubzilla.
And we have Nomad, which is Mike's latest protocol. It has occasionally been called Zot12 because it is a fork of Zot and the code has been updated, but it is considered a different and competing protocol that performs the same duties as Zot6.
Or, put another way, depending on your perspective, Nomad is either an updated version of Zot, or Nomad is a competing protocol. Perhaps it is both.
That was a reply to a comment that stated basically if Hubzilla adopted Nomad (there is no Zot12), one would need to drop federation with everything but Nomad and ActivityPub. Dropping federation with Diaspora in streams had nothing to do with Nomad compatibility.
Then it'd have to axe all connections except Zot and ActivityPub.
Not necessarily.- Streams supports three protocols: Nomad, ActivityPub, and Zot6.
Hubzilla supports Zot6, with ActivityPub, Diaspora, and others as an addon.
Hubzilla could add Nomad as an additional protocol, either in core or as an addon. This does not affect the other protocols it supports, now or in the future.
It only becomes an issue when a third party, say someone on Mastodon, tries to reach a Hubzilla site that does not have PubCrawl activated. From their perspective, federation is broken. From that hub's perspective, it is working as intended.
There is no difference between federation of other services between Zot or Nomad. Streams dropped federation with non ActivityStreams based platforms in streams as a usability issue. This has nothing to do with the Nomad protocol.
I'm tired of people complaining about seeing Hubzilla folks "talking to themselves" and blaming it all on Hubzilla having broken federation, when the only issue is that Diaspora doesn't federate with anything but itself. I'm not going through this with streams. You could add Diaspora federation if you want - it's just a plugin. But it will have to be a fork because I'm not accepting it as a pull request in the streams repository for the reasons stated. If you want Diaspora, you can also have all the complaints from Mastodon folks about your software's federation being broken. It comes with the territory.
I can't speak for Mario, but I suppose the number one reason is lack of resources. And then there is a cost/benefit analysis. Do the additional features justify the cost?
And you have to consider that Mike is experimenting with the latest cutting edge features. Nomad is still evolving. And many of the features in Nomad (Zot12) may wind up in ActivityPub, if Mike has his way.
Does Hubzilla need those features at this point? How can we be sure that Zot12 doesn't become Zot17 anytime soon? What if these features wind up in ActivityPub?
To me, it seems too early to commit to upgrading to Nomad outside of Streams.
Again, I am not speaking for Mario. That is just what my thought process would be on it.
many of the features in Nomad (Zot12) may wind up in ActivityPub, if Mike has his way.
Mike might have his way sooner, if there was more than one platform using zot12. And we'd get rid of the increasing distance between Hubzilla and Streams. Or for me personally i might switch to Streams then. I enjoy too many good company from Mastodon myself, coming to HZ from there just in the last spring. In fact the plus in features, that HZ has, remains almost unused by me today, running websites off CMS and no need fo a wiki.
Nomadic Identity is what has brought me here in the first place, among with the option to install this on my shared host without the use of docker or sthg like this. I suppose that'll remain the same in Streams.
@_jayrope I think it all comes down to resources at this point. If I had enough resources, I would personally commission developers to add Nomad, the Bluesky AT protocol, and possibly other protocols to Hubzilla.
But Nomad and Bluesky would need to be stable for that to happen, and right now both are still evolving.
Although it's not nomadic identity, some platforms such as Mastodon and Pixelfed might be supporting one way OpenWebAuth, which would allow people to remotely authenticate with their Mastodon or Pixelfed identity on a Hubzilla or Streams website (but not the other way around). If this becomes an official part of these projects, it may open Mastodon users up to the idea that their fediverse identity goes beyond Mastodon. I wonder what kind of effect that will have.
@jupiter_rowland Of course, I could always just ask my followers... and I might get an answer, too. But that's really not a great, elegant solution.
And yes, I can research all this, but I'm almost entirely sure I didn't join Mastodon to become anything remotely close to a developer, or to custom tweak my settings to be on the "bleeding edge", with the high possibility of breaking a half-dozen other things at the same time. 🙄
@Mark Kraft Obviously, staying on #MastodonSocial won't let you write #LongPosts. Not unless the devs raise the default character count.
One option would be to ask around which #Mastodon instances allow for more than #500Characters and then move there.
An even better option would be to ditch Mastodon altogether and move elsewhere in the #Fediverse. Then you won't have to ask around for instances with a high character count, and you can stay connected with the same people. Remember that #MastodonIsNotTheFediverse.
#Firefish, for example, offers 3,000 characters by default. Some instances offer even more. And it offers #TextFormatting through #Markdown including formatting that Mastodon still can't display.
There are Fediverse projects with even higher character counts. But another advantage of Firefish is that it can import Mastodon accounts AFAIK which makes moving easier.
@jupiter_rowland"An even better option would be to ditch Mastodon altogether and move elsewhere in the #fediverse"
But at that point, wouldn't it likely bring up other issues?
While Mastodon can see posts on Firefish, the question could be one of interaction, as is often the case with social media. A lot of that becomes an issue of "will they see me / find me by default" through standard use?
Being somewhere online because that's where others are is both frustrating & understandable.
But so much I can say: It should be as easy or difficult to find users on instances of wholly different #Fediverse projects as on different #Mastodon instances. The discovery process from Mastodon is the same.
I'm not aware of any search feature either on any of Mastodon's Web interfaces or in any mobile app that lists users from all across Mastodon, but none from anywhere else. Again, the discovery process is the same. AFAIK, it doesn't work by crawling user directories of instances because that'd require knowledge which instances exist. It works by crawling posts, finding posts and then checking those who wrote them. This is also the only way to discover instances in the first place.
In order for there to be an automatically-generated user list with only Mastodon users, it would require active filtering. The discovered users would have to be checked for which project they're on, and then those who aren't on Mastodon would have to be intentionally removed. Not only wouldn't this make any sense, but it'd be segregation and discrimination against anyone who isn't on Mastodon.
Being on a huge instance has only got its advantages either when you're new or when you have to start over from scratch. It gives you instant exposure on the local timeline, and the more people check the local timeline, the more people find you and may follow you. But those will only be people on the same instance as you.
Exposure on other instances comes different ways. You can reply to posts from other instances, and your replies will be read by people on these instances and appear on the federated timelines of these instances. You can follow people from other instances and hope they'll follow you back. If they do, all your own posts will appear on the federated timelines of these instances.
If you move to another instance, an important thing to do is to notify all your followers of your move. AFAIK, taking your followers with you is technically impossible outside of places with full #NomadicIdentity support, and this means everywhere that's based on #ActivityPub. You have to tell your followers where you're going to move, and then you have to hope that they'll actively follow your new account. But at least you've got followers to tell to follow your new account which will have instant exposure.
And in this case, it doesn't matter if you move to another Mastodon instance or to #Firefish or #Akkoma or #Mitra or #Friendica. It's all the same because following you works all the same.
@jupiter_rowland I will have to look into this more... #nomadicidentity is pretty important, to the point that moving elsewhere might not be the way to go until Mastodon supports it fully... but I might create something on Firefish and link to it when I do long posts. I've been looking for something that's not Medium, as I don't support Twitter's billionaire former owner, but do want to do some of what it does.
@Mark Kraft #Mastodon will never have full #NomadicIdentity support. That'd require its very structure to be completely overthrown. It would have to introduce the channel model from #Hubzilla and #Streams, essentially making Mastodon more complicated for newbies/X converts to get into. And either #ActivityPub would have to include nomadic identity, or Mastodon would have to switch to #Zot or #Nomad with an external connector for ActivityPub.
Even then, using nomadic identity to move elsewhere from Mastodon would not be guaranteed, and using nomadic identity to have a fully synchronous clone of your Mastodon channel on Hubzilla or (streams) would be impossible, having a clone on both more so. Even Hubzilla (Zot6) and (streams) (Zot12 a.k.a. Nomad) aren't fully compatible with one another anymore.
#Mastodon will never have full #NomadicIdentity support. That'd require its very structure to be completely overthrown. It would have to introduce the channel model from #Hubzilla and #Streams, essentially making Mastodon more complicated for newbies/X converts to get into. And either #ActivityPub would have to include nomadic identity, or Mastodon would have to switch to #Zot or #Nomad with an external connector for ActivityPub.
It's not as hard as it seem. Mastodon already had the ability to move an identity to a new instance/account. You even get to keep your followers. It is missing the ability to import all of your posts to the new account though, but that could be added without changing how Mastodon works.
But to be nomadic, the identities would need to sync, and that is where they would need to change things significantly. As far as ActivityPub goes, you only need a couple of additional fields and a platform that understands those fields. Streams already provides these fields, but no one else is paying attention to them. But they are there.
It could be done, but if it is done, it would most likely be just Mastodon to Mastodon... And I doubt they will ever be interested in nomadic identity for Mastodon, so it is a non-starter.
I think that the best we could hope for is that other platforms recognize nomadic accounts (i.e. me@example.com and me@example.social are the same person), even if their accounts aren't capable of being nomadic.
@Scott M. Stolz
Well, channels have the advantage that all your content is "containerised", so-to-speak. And the ID of the container can be independent from the domain it is on. That makes both #NomadicIdentity and multiple channels with different IDs on one account possible.
#Mastodon and the other projects based on #ActivityPub have no such containers. All content is lying directly on the account. Attributing it to a wholly different ID on a different instance might be kind of difficult.
No wonder Mike has introduced channels with the #RedMatrix back then.
It could be done, but if it is done, it would most likely be just Mastodon to Mastodon...
Well, truth be told, full nomadic cloning between #Hubzilla and #Streams isn't possible either. You can move from Hubzilla to Streams using the same technology as nomadic identity, but you can't create a nomadic clone. Vice versa is at least strongly disrecommended by Mike.
But if you could at least move from a nomadic Mastodon to Hubzilla or (streams)...
Well, truth be told, full nomadic cloning between #Hubzilla and #Streams isn't possible either.
There are two reasons for that.
The first is that Hubzilla and Streams are diverging in several areas, including database structures and protocols used. In theory, two platforms with different database structures could still sync if they agree on using the same protocol to sync the two. But Streams and Hubzilla have even diverged in that area, with Streams using Nomad (Zot12) and Hubzilla using Zot6.
The second reason is that you would have to coordination between projects to make it happen, and with the few resources we have now, that would be a big ask.
We have to consider that there are two levels of support for nomadic identities:- Remote systems understand that me@example.com and me@example.social are the same person.
The ability to sync nomadic channels.
Hubzilla and Streams have a nomadic identity support level of 1, but since Hubzilla and Streams can't sync, they don't support level 2 between them. Hubzilla only supports level 2 with itself. Streams only supports level 2 with itself.
I'd just be happy if ActivityPub users would continue to be connected to a nomadic account even after you change your primary channel address (i.e. level 1 support).
Vice versa is at least strongly disrecommended by Mike.
I don't care if you go the other way, but you should probably translate data formats if you don't want to trash your database. That's all. I'm not going back to ActivityStreams1, we're too far beyond that now, but I'm not stopping anybody else from writing a data mapper. And if you can map both directions, you can sync both directions.
@jupiter_rowland it is true that would be better from a similar standpoint from which it is better to move to firefox for example, I suppose. There is nothing inherently wrong about using Mastodon though.
It would be really useful if the #databases added #characterimit as a search term. That's the only real issue I see here; people can't find what they want, so they moan.
For example, if you could #search one of these, it would more or less solve this for most users.
@marqle Seems a good sugestion to add character limit info to @poduptime - #FediverseObserver is biased otherwise, though, as upon initial visit one gets offered local Mastodon servers only. That is Mastoverse, not Fediverse. If they'd compare character limits among softwares already on the first page there'd be a way different base of choice for users.
I do enjoy (another) account on a Mastodon server, that is not character limited to 500, but it took two years to find oen at all. If i had known #Hubzilla at the time I'd have used that right away.
But most people will hear about #mastodon first and there are many #mastodon instances with longer limits that would suit those people perfectly, if only they could find them easily.
@marqle The second instance you've mentioned is a specialised instance for the #Belgian #PirateParty, by the way.
Generally, a #Mastodon instance with a higher character count will only have one advantage: It's the same as what people are used to, only with more characters.
The disadvantage is that they're hard to find. And they aren't that easy to move to.
#Firefish, in comparison, offers you 3,000 characters and more on all instances. You don't have to ask which one has over #500Characters because they all do. And you get quotes, text formatting and years of running full-text search on top. And it's fairly easy to move to from Mastodon.
But I guess it's just as hard for people to let go of Mastodon and move elsewhere in the Fediverse as it was for them to let go of Twitter and move to Mastodon. That's why it always has to be Mastodon, Mastodon, Mastodon without ever even considering one of the other micro-blogging projects.
I definitely take you general point there. I think #firefish is the best piece of server #software the #fediverse has produced and I use it almost as much as i use #mastodon
On your other point, yes the #pirateparty instance is specialised, but when you really look around, they're getting more common.
And the #admin#rationale seems logical to me. I'm sure they reason, a generic instance is fine with 500 but a topical instance requires more space to argue and debate.
@jupiter_rowland While I agree with you, I think you're kind of exaggerating the likelihood of this. Most developers and many people running instances, in particular, wouldn't be so inclined.
I think it might become a "kind social practice" to have a CW for long posts, but in truth, most people won't bother. The old school of tightly constrained politeness is fading, I think.
Also, there are many of us on Mastodon who view posts through things like #Elk, which display text formatting.
I am starting to think that the reaction we are getting has nothing to do with post formatting or being over 500 characters. I think it is part of an us vs. them thing. We are not part of their clique. Enforcing their clique's community rules is their way of saying we are outsiders and don't belong. To them, we are outsiders encroaching on their territory.
If that is what is really going on, there is no level of appeasement that will please them.
When I was younger, I was a people pleaser. And one thing that became obvious is that you can't please everyone. I still try to make people happy, but I am more realistic about it now. Some people you just can't please.
The loudest people are usually the minority. The majority vote quietly with their time, money, and resources. They simply go elsewhere, do something else, or spend their money differently... and they usually don't say anything.
I don't think all of Mastodon will isolate themselves. However, I do believe that various communities within Mastodon will isolate themselves until they are in a bubble. And that is their right. People get to choose who they associate with and which content they consume.
But, realistically, people who are going to complain about bold and italics are going to complain about everything else. And, based on past experience with people who routinely complain about petty things, some of them get so aggressive about it that they need to be blocked. We have "no harassment" and "no bullying" policies on our servers. I try to be accommodating, but becoming aggressive is not acceptable. So if they block me first, that saves me the trouble of blocking them.
Luckily, it isn't everyone on Mastodon who overreacts to things they don't know from vanilla Mastodon. And I myself have yet to see someone complain loudly about people actually formatting their text and demand that stop. But I think I've read about people reporting users to admins who refuse to issue content warnings, maybe even in cases where there's no consent if a content warning is actually necessary.
But I know that some Mastodon users are speaking out quite loudly against anything that other Fediverse projects bring into Mastodon that Mastodon 3.x didn't have yet. For example, posts with over 500 characters. And there has always been vocal opposition against any traces of text formatting on Mastodon. It might come back, now that Mastodon can display text formatting.
I can't say for certain if and how far any of this opposition will escalate. But I know that some people are actively blocking anyone who ever posts over 500 characters, regardless of whether or not they know that there's a Fediverse outside Mastodon, and that everything that isn't Mastodon supports thousands of characters.
What I could imagine happen is Mastodon users trying to complain to admins of instances from which things come which aren't typical for Mastodon. How they dare make these things possible.
But they'll fail because they can't find out who the admin of a non-Mastodon instance is. They might be able to find that out if they used a Web browser. But almost everyone on Mastodon only ever uses Mastodon through dedicated Mastodon mobile apps. And what can't be accessed through their Mastodon apps can't be accessed at all. This includes the siteinfo pages of Hubzilla hubs.
Even if they did find the admin of a Hubzilla hub, they couldn't reach the admin. They might be tempted to simply drop a public post that mentions the admin. This works on Mastodon and generally between ActivityPub-based projects, but it does not work with Hubzilla channels that don't follow them, and they don't know that. Even if they're smart enough to send a PM, the admin could have blocked PMs from non-connections. That's completely impossible on Mastodon, and so Mastodon users couldn't imagine that something like this could possibly exist.
By the way, I've actually come across someone who said that Hubzilla sucks because the devs flat-out refuse to throw its fine-grained privacy and permission controls overboard and make communication on Hubzilla identical to Mastodon. Well, you can't please everyone.
That said, I don't think Mastodon itself, i.e. the devs, will want to isolate Mastodon from the rest of the Fediverse. They might want to assume at least indirect control over the whole Fediverse by forcing it to do things the Mastodon way. But they can't really afford the rest of the Fediverse splitting off Mastodon. Even they have to admit that Mastodon's federation with dozens of other projects is a killer feature.
@Jupiter Rowland It sounds not so urgent. Probably recommended to just wait and see how people might actually be quite relaxed about all that. The few who scream loudly aren't the majority, usually.
I understand. I do. I have PubCrawl on. But PubCrawl is more than Mastodon. That is why I have it turned on.
I think a lot of Mastodon users and admins are treating Mastodon as if it's a Facebook group they moderate. They kick anyone out of the group they don't like.
I think that some people want a social bubble. The whole idea that someone might do or say something they don't like is upsetting for them. If they can't handle bold and italic text, then maybe it's a good thing they block us. They're more comfortable and I don't have to listen to them complaining about me using bold and italics. They have a right to not want to see bold and italics, and I have a right to use bold and italics.
If Mastodon keeps going this route, building walls and a big moat around themselves, eventually they will make themselves irrelevant to the fediverse. Hard to imagine now, but the more they isolate themselves, the more they become an island. And there are a lot of other projects that are coming up.
And thanks for mentioning that they will contact the admin of the instance. I will make sure that I publish a link to our ticket system so they can report people. I will gladly respond to them explaining that the fediverse is not Mastodon and Mastodon cultural rules don't apply. They may not like that response, but it is something they need to hear.
I am a "live and let live" sort of person. They should do what is best for them. But I don't believe people should be bullied to comply with someone else's personal preferences.
I don't know if you even have Pubcrawl on. Many of those who are really deep into Hubzilla or (streams) don't.
But Mastodon users go beyond simply not following you. Blocking you for not complying with Mastodon's cultural rules is not uncommon. Yes, even if you aren't on the same instance as them.
In fact, even if you aren't even on Mastodon yourself. I guess 75% of all Mastodon users couldn't tell right off the bat if a post didn't come from Mastodon unless, maybe, it actually showed something that's impossible to do on Mastodon such as text formatting. And I guess some 50% of all Mastodon users don't know that the Fediverse is more than Mastodon. They'll think you're on a Mastodon instance that allows users to do wacky stuff for some reason. Or they simply don't notice half of what you do because their mobile app can't show text formatting.
No, Mastodon users would go even further. Like, try to contact your instance admin and have you "moderated".
Unfortunately for them, mobile Mastodon apps might show who's the admin of another Mastodon instance. But they don't show just the same who's the admin of a Hubzilla instance. Not only because they're all built hard against only Mastodon, and Hubzilla doesn't even have an API that can tell an app who's the instance admin, but also because many Hubzilla instances don't even mention their admins at all.
Thus, all Hubzilla instances fall under "no moderation". Which might be justification enough to have them Fediblocked.
Oh, and yes, Mastodon users are that sensitive. And if they're halfway experienced and savvy, they know how to react upon things that trigger them.
I have a challenge for you and everyone else who has Pubcrawl off: Turn Pubcrawl on. Get a few bidirectional connections on mastodon.social so that your posts appear in the federated timeline. Let a few dozen or a few hundred newbies follow you just because they need their personal timelines to be buzzing with off-topic cruft so that Mastodon feels more like X. And then post a few pictures without adding an alt-text.
Add comment