The initial clone is made either via a thumb drive or API request to an existing identity instance during account/channel creation. After that these are synced via the 'sync' message type of the Nomad protocol.
Uhm, we may have gotten wires crossed somehow. Streams supports Mastodon's Move activity and moves a fediverse account in accordance with the procedurre used by Mastodon. This has nothing to do with Streams nomadic identity mechanisms.
Nomadic identity does not use the Move mechanism, because a copy was already made and there is nothing to move. Streams does report nomadic instances in alsoKnownAs and provides information that a nomadic clone was created (as opposed to a one-time migration) via the copiedTo property. Sites and projects which wish to support nomadic identity may make use of these properties to discover and link the different identifiers.
And as it relates to fep-7628, we provide the "copiedTo" property in ActivityPub as an analogue to Mastodon's "movedTo" property. It has the same semantics as the Mastodon property except the original identity isn't deleted. This is documented in the FEDERATION.md document of the streams repository.
I provided my input to the AP spec editor and it was rejected outright. Everything I provided to the ActivityPub editor was rejected outright. If there were any questions, it had to go through the Mastodon dictator, who rejected anything he didn't invent. And then the ActivityPub editor would likewise reject it. "Mastodon has millions of users, you don't".
That's the way the process works.
The major concern was that nomadic identity is hard, and the clock was ticking on when the spec had to be finalised. The ActivityPub editor also insisted that it be done using the draft digital identity spec. So that ensured it would never make it into ActivityPub.
Here we are 5-6 years later and they still can't figure out how to do nomadic identity in a decentralised framework (outside of using torrents or centralised resolvers). Meanwhile we've had it, used it, and improved it for well over a decade.
There's a specification in the public domain. Some complain that it isn't enough, but I'm one person in a planet of 8 billion and haven't had any help developing this. The only help I ever get is with bike shed stuff - web interfaces. Not one person has offered any help polishing up the spec or improving the actual implementation code or even offered critique and discussing the subject. Just "I can't use this. Bye." [edit: apologies. That isn't entirely correct. I did get help from one person.]
I've started to pick it up and try again using did's as a proof of concept, but I'm retired now and really can't be bothered dying on the same hill over and over again.
But I will try and update Nomad (the protocol, formerly Zot) to use a did: form. It's just a replacement WebMTA for delivering JSON ActivityStreams which is nomadic aware. There's still no chance of it ever getting into ActivityPub unless it's invented by the Mastodon dictator.
Meanwhile the spec is in the public domain and there are working implementations and it federates with ActivityPub and nobody is holding a gun to anybody's head.
Ironically the definition of the fediverse from wikipedia which was cited in the article has changed dramatically over the last month or two by a very aggressive editor with an agenda.
"Can you imagine using any social media without block functionality?"
It's actually fine if you start off with a working permission layer. We only added blocking in 2014, and rarely if ever use it. Don't need it. If people are coming into your living room behaving like animals and murdering your guests, sure, you can kick them out. You could also just close the bloody front door - and only let your friends in. Same result- but without all the dead friends.
But X is removing blocks and never even had a concept of permissions. We already know how that story ends. I've seen it play out over and over and over again in my 40+ years of doing decentralised communications.
Thanks to a comment in one of the federated search threads, I'm currently merging our federated search implementation with opensearch. In case you missed it, I have serous reservations about Mastodon's proposed implementation. The fediverse is not a dictatorship, and ideas spread here based on merit and consensus, not decree. But I'm not here to throw rocks. I'm here to present an alternative.
Permissions are based on the 'canSearch' attribute, which is an array of actors, groups, lists, follower collections, etc. which are allowed to search each channel. A public search will contain the ActivityPub public inbox, for example. An empty array means nobody can search your stuff.
A site search is the aggregation of individual channels on the site that allow the visitor to search their content; and the instance provides its own 'canSearch' attribute for the actor record of the instance (at the site root). So each search requires permission up and down the stack with you providing the final say. This has no linkage to user discovery; which uses a separate permission.
Searches return ActivityPub collections when fetched with ActivityPub headers, Nomad collections when fetched with Nomad headers, and text/html when fetched with a browser. Pure fediverse implementations need only support ActivityPub. Would be quite happy to work with other federated communities on further standardisation and refinements. For now you can provide feedback and discuss this in the @Streams group (https://unfediverse.com/channel/streams) and I'll create a separate working group if there's enough interest. Would love it if somebody would like to step in and create the FEP for this as my available time is quite constrained. This implementation will run on a rasberry pi or shared hosting using any search backend you wish to implement.
What opensearch brings to the table is a standardised and mature specification related to discovery of the search endpoint(s).
Since we already support federated search based on this model and also have long-standing support for opensearch, merging these should be not be terribly difficult -- and is currently in progress.
In the conversation model, all comments are sent to and re-delivered by the "owner" of the top-level post in the conversation. That's in quotes because the owner isn't necessarily the author. In fact it is the 'sender'. The owner also sets the privacy for the conversation, and can remove comments from the conversation or delete it completely. It belongs to them. The mechanism supports things like private groups and 'circles/aspects' because the conversation owner is the authority of who was addressed in this conversation. They are the only entity that knows specifically who was addressed, which may be private lists they control and which nobody else has permission to enumerate. If they relay all the comments, the conversation remains complete at all nodes that received the top-level post.
In practise, (and here is where we differ significantly from the 'posts' model) -- you still have threaded conversations, and you still specify the inReplyTo field to indicate which comment you are responding to, but you still must send the post to the conversation owner for delivery -- who delivers it to everybody in the original conversation audience accordingly. You cannot change the privacy to something else or inject DMs in the middle of the thread. The conversation does not belong to you or the person whose post you're commenting on. It belongs completely to the sender of the first post in the thread. What's interesting is that Diaspora and Friendica developed the exact same mechanism simultaneously and independently for supporting conversation privacy.
I'm currently adding the price and location data to the post in the streams repository (since we provide distance search and other location services). Suggestion: It might make sense going forward to use the standard ActivityPub location (Place) schema for this and put it on the activity instead of inside a custom element with non-standard attributes. We support that already and then the only special thing I would need to extract from the flohmarkt data element is the price.
What's required to provide a remote interact button? We do support remote interactions in streams via the ostatus webfinger follow template (similar to Mastodon) so this shouldn't be too difficult to add.
When following an instance, the delivered posts are public posts on the other instance -- aka the "site stream". No private posts or private media are included.
You can follow it by putting the baseurl of the site into the 'new connection' box. To unfollow, delete the connection. This does not remove any other you connections you have on that instance.
This has been available for quite some time, but has only been lightly tested, hence my message. I'm just trying to increase exposure. If you encounter any issues or have suggestions, you know what to do. The original intent was for sites to connect with each other into federated community groups and make content discovery easier for smaller sites by following larger (trusted) ones without needing to enable the horrid 'public stream'. It wasn't until later I thought about letting normal channels follow instances, and sure, why not... Anyway that's the concept. I fully expect that it will evolve in ways I never anticipated.
This will probably only work with instances of the streams repository because it represents a third party relay. Might work with Mastodon which supports LD signatures but a lot of projects will just toss the relayed posts.
It's also theoretically possible to turn the site actor into a group. Then it should behave slightly different from what I described and appear to others as a bona-fide group. I don't remember if this part works or not. I haven't looked at it much in the last 2-3 years because I've been busy with other stuff.
This isn't about Mastodon doing microblogging stuff. They can do what they want. But when it comes to interoperability with other software using an internet standard protocol, this is about Mastodon supporting the specifications of that internet standard protocol.
By default, the value of content is HTML. The mediaType property can be used in the object to indicate a different content type.
Note it doesn't say the default value of content is "text/plain with 'a' tags". It says "HTML". From memory, HTML supports a few more tags besides 'a'. That's in a different set of specifications, if you want to verify. Specifications are important for standard protocols if you want different things to work together.
We provide ways to monetise your instance with tiered service plans, since we have basically unlimited personal cloud storage; and any one person can use up all your available resources with their pirated video library or a 30TB backup. Or as we discovered building Friendica -- if somebody lands on your server with tens of thousands of Facebook friends and all their content.
Tiered services let you limit accounts by file quotas, number of friends/followers, number of channels or cloned channels per account, number of posts per day/week/month, total number of posts, etc. for free plans -- and drop the limits for paying customers. Instance admins can choose any combination of service limits and define their tiers. So far only a few people have done this , but this has been possible for at least a decade. Most of our instances are personal or family spaces and we don't have any public "project" instances; because we're not capitalist pigs trying to achieve world domination. We just provide cool software. It's up to you what you want to do with it.
Friendica is OK, but the best Facebook alternative is streams. Feel free to disagree; but if you're discussing Facebook alternatives, you would be foolish to ignore this very capable but also very different way of looking at decentralised communications and the fediverse. If the fediverse goes down the tubes after Barcelona becomes a thing, no worries. First of all it's unlikely it will even affect us, and second, if it does -- we've got options you aren't even aware of. We've been living under the threat of EEE for years and our defenses have evolved accordingly.
Why should my opinion matter? I created Friendica.
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.