Notices by Mike Macgirvin (mike@macgirvin.com)
-
Mike Macgirvin (mike@macgirvin.com)'s status on Friday, 22-Sep-2023 18:01:15 JST 
Mike Macgirvin
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. -
Mike Macgirvin (mike@macgirvin.com)'s status on Thursday, 21-Sep-2023 22:44:08 JST
Mike Macgirvin
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. -
Mike Macgirvin (mike@macgirvin.com)'s status on Saturday, 16-Sep-2023 12:03:25 JST
Mike Macgirvin
The identity and all the locations are signed with the same key. -
Mike Macgirvin (mike@macgirvin.com)'s status on Monday, 11-Sep-2023 13:51:40 JST
Mike Macgirvin
There is a clear ambiguity in the spec if you wish to make use of this. Arrive and Leave are considered 'Intransitive Activities' where "the object property is therefore inappropriate". I completely disagree. We accept and generate activities of Arrive/Note and Leave/Note as long as the Note has a location field. This lets you describe the place you've arrived at, in a form much like Facebook - which I'm fairly certain was the motivation for this property.
We'll also let you do a distance search for any Note that supplies a post location.
https://unfediverse.com/help/guide/en/Location_Services -
Mike Macgirvin (mike@macgirvin.com)'s status on Wednesday, 06-Sep-2023 06:10:36 JST
Mike Macgirvin
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 [edit: and can be an array]. This is documented in the FEDERATION.md document of the streams repository. -
Mike Macgirvin (mike@macgirvin.com)'s status on Wednesday, 06-Sep-2023 05:45:51 JST
Mike Macgirvin
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.
https://codeberg.org/streams/streams -
Mike Macgirvin (mike@macgirvin.com)'s status on Wednesday, 09-Aug-2023 23:00:46 JST
Mike Macgirvin
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. -
Mike Macgirvin (mike@macgirvin.com)'s status on Sunday, 06-Aug-2023 03:31:55 JST
Mike Macgirvin
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.
Cheers. -
Mike Macgirvin (mike@macgirvin.com)'s status on Tuesday, 20-Jun-2023 05:35:58 JST
Mike Macgirvin
And streams is the name of a repository. There is no brand or fediverse project with that name.
F*ck brands. -
Mike Macgirvin (mike@macgirvin.com)'s status on Sunday, 07-May-2023 21:54:18 JST
Mike Macgirvin
(streams) current privacy settings. -
Mike Macgirvin (mike@macgirvin.com)'s status on Tuesday, 25-Apr-2023 10:31:29 JST
Mike Macgirvin
We'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. -
Mike Macgirvin (mike@macgirvin.com)'s status on Tuesday, 25-Apr-2023 10:30:31 JST
Mike Macgirvin
So here's the high level overview...
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. -
Mike Macgirvin (mike@macgirvin.com)'s status on Tuesday, 18-Apr-2023 20:45:08 JST
Mike Macgirvin
My goal is for the fediverse to replace email. Nothing less. I've been working towards that goal since Eugen was still in diapers. We've got a long way to go because everybody else seems to be focused on burying a dead bird. Throw some dirt over it and move on. -
Mike Macgirvin (mike@macgirvin.com)'s status on Saturday, 15-Apr-2023 23:23:34 JST
Mike Macgirvin
Anyway ---- I was looking through the code and remembered we have a basic infrastructure for cross-platform id. You know - so you can link your streams account and your mastodon account and your pixelfed account. There were a couple of issues with it at the time (this was five years ago). But I just didn't put enough controls on it. So your streams account could be the central coordinating account or some fediverse project I never heard of could provide that role. We don't really care what technology is used to link the accounts. Could be OAuth or OWA or rel-me or DIDs. And for each of these linked accounts, offer a decision so that they automatically boost or attach and resend locally. anything sent from that identity. Or not. And send your posts/comments from this identity to that identity. Or Not. And Bob's your uncle. Cheers. -
Mike Macgirvin (mike@macgirvin.com)'s status on Friday, 07-Apr-2023 21:33:23 JST
Mike Macgirvin
Announce: streams release 2023-04-07 - https://codeberg.org/streams/streams
"The best fediverse server you never heard of".
All ０７６萌ＳＮＳ content and data are available under the