There was some lively discussion on the socialhub and I thought we were making progress, but now I'm not so sure. Talks have broken down. Mastodon appears to be moving ahead and don't care what I think or what it will do to the fediverse. We already have comment permissions and don't even need FEP-5624. If that document is played as is, we will no longer be able to federate with Mastodon - full stop. The fediverse will slow to a crawl and server costs will skyrocket because network traffic will triple - just to continue federating the exact same number of messages.
Hopefully without extinguishing the only projects with working comment controls in the process. We're not the enemy. I'm happy with having a canReply field. We support that. If somebody replies and they aren't allowed, just drop the reply. Period. Possibly send a Reject. We don't need to send signed approvals to everybody involved in the conversation. That is the most Rube Goldberg thing I've seen proposed yet. It doesn't scale. It will cause a civil war in the fediverse. If that's what you want, please unfollow me.
Told you so, years and years ago. Repeated it over and over. "Mastodon is building a spam gateway so big you can drive a fleet of starships through it. Eventually the spammers will discover this. This is not a matter of 'if', only 'when'. "
Tried to enshrine comment permissions in OStatus and ActivityPub before either were widely deployed. People laughed. Evan muzzled me and prevented me from speaking out. Cwebber ridiculed me publicly. Gargron ignored me completely.
So here we are.
Folks it has only just begun. Streams and Hubzilla will survive. Don't know about anybody else. Stop building fucking spam gateways.
Renaud Chaput wrote the following post Wed, 17 May 2023 16:53:23 +1000Hugops to every other #mastoadmin having to deal with this spam wave. We have been fighting is on mastodon.social for days, and were forced to close registrations yesterday until we could emergency-deploy countermeasures. Unfortunately, this made them realise they are other servers in the Fediverse to target. If any admin needs help fighting this, please ping me either on the server admin discord, or directly here, and I will gladly help.
True nomadic identity, comment control, rich permissions, groups, circles, quoted posts, single sign-on to the entire network, rich media, integrated cloud storage, decentralised, public domain ActivityStreams. Everything that bluesky and nostr and activitypub promised, but all have failed to deliver.
Friendica once had moderate comment control. The current devs removed it.There's always streams if you want to see what is possible when you aren't ruled by market share and just want a safe space with cool tools.
Embed this noticemike (mike@macgirvin.com)'s status on Tuesday, 02-May-2023 19:07:54 JST
mikeSo the "heavy lifting" on the Fediverse Identity Manager is pretty much complete. Now I just need to assemble all the components and test them as an integrated unit. Don't get me wrong - there's still a fair chunk of work involved, but it's all downhill from here. I'm thinking maybe another week or two before a public preview.
Upgrade instructions: Visit your admin page and click 'Update'.
Some of the things I've been working on this cycle:
Fediverse Identity Manager (in progress, ~70% complete).
Remove unused Group Notification preference setting. These notifications are already present in your stream notifications.
Fixed post/comment backfilling so new connections arrive with some posts and context.
Bug: Manually deleted posts now stay deleted and don't come back. Automatically expired posts will come back if they are later updated.
Redirect successful remotely authenticated visitors to the Apps page instead of returning to the login page.
Fixed a couple of postgres specific issues which surfaced now that more people are using that database engine.
Issues with automatically hyperlinking "naked URLs" in text after recent re-organisation of multicode priority.
Fixed a few obscure multicode conflicts due to markdown getting processed before HTML and bbcode.
Fixed display issue of oembed links over ActivityPub (does not affect Nomad).
Fixed exception which occurred if the (optional) imageMagick package wasn't installed. This should degrade gracefully.
Worked through a few issues which prevented connecting with topics on lemmy. This is ongoing as that project has unique interpretations of some of the official specifications.
Activity id element was misconfigured for Events, which made these difficult to search.
Added DNS (sub-domain) discovery for actors per FEP-612d
Fix rounding errors which allowed some poll results to add up to slightly more than 100%
Re-factored video imports from personal cloud storage so the video will not be embedded twice.
Fixed an obscure issue where people with a comma in their display name had messed up notifications.
Site search now returns a page with 'permission denied' rather than a white screen if you lack permission to search this site.
Fixed regression introduced in last release where some HTTP signatures would fail if the keyId contained query parameters
-- When safe online spaces are outlawed, only outlaws will have safe online spaces.
The first component is your external identity manager. This will behave somewhat like Mastodon's current external account verification interface. Links are created based on the existence of a secure relationship with rel="me" links (secure meaning https with no http redirects in the redirect chain).
This module just creates and manages verified links.
The second component is the Channel Manager (which anybody using streams or zap or hubzilla is already familiar with). This currently provides a selector for your local channels (on this instance), and channels you can moderate (on any instance). What we're going to do is add another section so you can teleport to your external identities (which includes nomadic identities and any rel="me" identities you added via the external Identity Manager). So basically a single dropdown will let you visit any of your identities from the channel menu. OpenWebAuth would be nice, but chances are high that you've got a long-life cookie on these sites and it will work without authentication.
This gets you 90% of the way there.
Next comes the Channel Sources module which lets you re-publish any posts that arrive from certain connections. Anybody with a rel="me" relationship will automatically become potential channel sources. This lets you automatically re-publish any content that you published on these separate accounts to your streams channel (with an optional category or tag, depending on the source). So your streams account can (if you want) be a central aggregator for all your fediverse accounts and will boost or share all the content from your additional identities to the followers of your streams identity. This part is completely optional if you want to have separate followers on each service.
This provides the basic functionality. Then further down the road, we'll probably do some follower merging from your linked accounts and let you address these external followers to your other accounts from posts you make in streams. The goal is provide the inverse of using your streams account as the aggregator, and let you use your Mastodon as the aggregator (for instance). This may not be possible unless the other service provides re-publishing tools. But I'm also looking at some other possibilities since I don't like depending on any projects which are resistant to innovation. Will try to find a way to achieve our desired goals without requiring any other projects to evolve.
That's the high level overview. As always, once these pieces start coming together, the feature is likely to evolve in different directions as people start to explore the new possibilities.
Embed this noticemike (mike@macgirvin.com)'s status on Tuesday, 25-Apr-2023 09:30:38 JST
mikeWe've discussed this earlier... Currently working on federated identities for the #fediverse. You know, to link your Akkoma account with your Pixelfed account and your streams account - and maybe your Mastodon account (if any of you have one of those). Hoping to have at least an identity management interface to demo sometime in the next several days.
He's probably right - if you're only talking about Mastodon. As soon as you change it to "the fediverse", it's a totally different ball game and bluesky is down by 103 in the ninth with two strikes.
We went through this with Diaspora years ago because they insisted that following hashtags was the only mechanism they would ever support for what I'll just call "community" posts.
Following hashtags leads towards centralisation because large sites have more easily available and more complete hashtag search results. Then they started coming up with new protocols to relay hashtags and make them more easily collectible and that's when the spam took off.
I said it then and I'll say it now. The better solution is groups - which we've supported in one form or another since about 2010. You can eject bad actors from a group. You cannot eject bad actors from a hashtag.
When you do search hashtags, we've since added features to let you decide what is hashtag abuse or not. A hashtag will match your search if there are less than 'n' total hashtags in the post. You get to define 'n'. From our federated search interfaces a search for #hashtag<5 will returns search results for #hashtag -- only if there are less than 5 total hashtags attached to the post.
In any case we still support hashtag search because our audience demands it. But it's a dead horse. Mastodon has gone the same route as Diaspora because "groups are hard". Yet we've come up with a dozen different ways to federate groups and the FEP process has whittled this down to two contenders. Mastodon groups are in progress, but they've kind of been in progress for five years. Get with groups people. We've already seen how hashtags end. The fediverse has public groups, private groups and moderated groups today. And as far as I know they all work with Mastodon.
I will caution you to avoid Friendica groups if you're running a raspi or small server. If you follow them, be careful when commenting. Your little garage server for friends and family could suddenly be tasked with delivering a few hundred thousand comments. That was a poor design decision on Friendica's part which I hope gets corrected. (In the interests of full disclosure I created Friendica, but left that project a decade ago to tackle bigger federation issues and have no direct involvement in that project today). Other groups implementations correctly put delivery of large group posts completely in the hands of the large group and not to individual commenters for this very reason. It will literally kill smaller servers.
I'll try to simplify because this knowledge is essential for anybody trying to build off of Nomad.
In Nomad, the channel guid is your 'claimed' network identity. In ActivityPub, both the channel URL and webfinger address are your 'claimed' network identity.
The difference is that under ActivityPub, the identity cannot exist without a server. Under Nomad, the identity is not tied to any server, but only to the guid.
In either case your claimed identity is then signed by you with your private key. The signature is the 'proof' of your claim.
When using Nomad, you also sign your current location (the site URL).
This isn't needed for ActivityPub because you only ever have one server. If you change servers, you need a new identity and anything that was ever stored with the old identity will need to be fixed.
On the other side of the conversation, the receiver receives something from you. It is the receiver's responsibility to fetch your public key and verify your signature, or in the case of Nomad signatures as we verify both your identity and location. Assuming your public key verifies both, we have now proven the 'claimed identity' and verified that the message was sent by you and also that your channel is currently using this location.
Once we have done that, the receiver generates the "xchan_hash" or as we call it in later versions - the "portable_id". This is a hash of your guid and your public key. Everybody on the network calculates the exact same portable_id for your channel. There is nothing secret about this and you can pass it around (and we do), but the only rule is that we never rely on a portable_id generated by anybody else. We can only use or rely on a portable_id we generated ourself after verifying your claimed identity. Otherwise it's just another 'claim' and could represent anybody. Once we've verified your identity and created this hash ourself, we can use it internally to refer to your identity - no matter what server you're using. And if you move servers, we don't need to change any existing data because your identity didn't change. All we need to do is add another location to those which we've currently associated with your identity.
I'll stop there, as adding any more information would just make it all too confusing. This is the essential explanation of how Zot/Nomad works. Everything else is just passing messages around.
Instead of a group owner relaying/deleting a post/comment to their group, what they can do instead is create activities to add or remove it from their inbox collection (or a collection devoted to a conversation), which accomplishes the same thing. This is entirely legal, even with Mastodon's interpretation of the relevant specs.
I use this channel primarily to discuss my personal life including music, sustainability, and my farm in Bugger All, AustraliaFor technical discussion, such as my open source projects and my work on data resilience, nomadic identity, online safety, and the fediverse underground, please see mike@unfediverse.com.