Show Navigation
Conversation
Notices
-
I've got server-to-server magic-auth and API magic-auth working. You probably won't be able to appreciate what this means until you start seeing magic zot apps and integrations that you never thought possible. I've got a few of these in mind already. It sort of means you can access anything that's visible to you anywhere in zotland from any device anywhere. And not just you. Any of your friends from any other network can access anything that's visible to them in all of zotland from any device anywhere.
-
Sounds exciting! What's one of your ideas for apps/integration?
-
One of the first things that comes to mind is standalone or mobile apps which access some facet of Hubzilla, like photos or file browsing. So you could create a media browser for the entire network that lets you see any photos or videos you are allowed to see. This isn't restricted to Hubzilla members. You could give the same app to a Diaspora or GNU-Social member and it would work the same - they could see a different set of files depending on who they are connected with and what they are allowed to see. A hubzilla member is only involved in creating the permissions. Anybody in the universe can then be in the access list. The only requirement is that they have a private key to sign the requests and this could be provided by their own social networking software or created automatically and downloaded to the app. Or they can generate their own key and use that. It's magic-auth on steroids.
-
And writing such an app could theoretically take an hour or two. You're just making JSON requests and displaying the results. That's it. You could spend a week on the UI and still shock and awe people with your programming skills.
-
How is server-to-server magic auth different from current remote login ?
-
We currently use a login session somewhere in the hubzilla network to verify your identity. If you visit a new site they need to refer back to your login site to verify your identity and transfer your browser session.
With the server-to-server or API authentication method, you eliminate the need for a login server. You can authenticate directly from an application to any node in the network without a password.
-
Without having access to the code right now, I'm guessing that you are downloading your private key to the client app, which then sends a signature using this key when requesting data from remote hubs. This signature is sufficient to verify your identity and thus determine what data you have permission to access. Is that close?
-
I semi-understand things virtual, but this sounds exciting.
-
So it isn't clear to me why it is called "server-to-server" if there is now one server involved instead of two previously?
-
Andrew has it. The 'server-to-server' is basically to distinguish it from zot magic-auth which requires a browser (a client) and uses cookies and server-to-server communication to link those cookies across domains. Signature auth cannot (yet) be done in the browser so you need to use an app that can do the backend auth (server to server) on your behalf. This app has a copy of your private key. So it can authenticate and/or authorize you anywhere in the network. But the 'server' in this case could be your pocket phone or desktop.
Immediately, we are using a not very elegant means of syncing files across clones. It's secure enough for the job, but this new mechanism makes it easy peasy. The other immediate application is to provide caldav services to your hubzilla calendar, without requiring you to store the password to your current server on your current server in a way that's reversible. I tried several ways of solving this problem, but they all had issues. This one works. I'll be moving forward with both of these in the near future.
I'm hoping that others will start getting excited about the possibilities this opens and start taking it in new directions because it really is a game changer. We have an infrastructure that can make use of it today so the hard work is done, but a few little extras could blow this wide open and provide private decentralised services that nobody has even thought about yet because nobody has ever had this capability before.
-
I could use some sketching and Alice, Bob and Charly to fully understand the implications but I grasp it more now, thanks!
-
That sounds super interesting, Mike.
One of the first things that comes to mind is standalone or mobile apps which access some facet of Hubzilla, like photos or file browsing.
I have been idly wondering about integrations recently, and have been extremely interested in what level of OS integration could be provided. In theory, Hubzilla could be set up as a Gnome Online Accounts (GOA) provider. GOA is kind of reminiscent of how Apple does integrations for social networks, storage platforms, instant messaging, etc, except of course it's free software.
What would be particularly interesting, from my point of view, would be to integrate Hubzilla tightly with a desktop Linux environment. This could include:
- Cloud Storage (like DropBox or Google Drive)
- Stream (Corebird-like status app.)
- Contact Sync
- Notifications
- Calendar Sync
- Notes
- Photos
- Events
- Messages
Some of these things already work, since Hubzilla uses DAV. Effectively, you could have a drop-in replacement for iCloud, allowing Hubzilla to act as their main data provider for devices and individual applications.
-
At least you understand the implications of what we're doing. I think it's lost on a lot of people.
Ironically hubzilla integrates fairly well with KDE since the K web browsers and DAV services share a cookie file. So magic auth works with DAV. Gnome does things a bit differently and it isn't as seamless.
This new capability makes integration with these kinds of services a *lot* easier. You no longer require a zot infrastructure to access private web objects. All you need is your private key.
I wasn't even looking at integration at these layers, but at a much lower level - by tying it to the OS through PAM. But perhaps that's the direction we should be moving - upwards to the application layer.
Mike Macgirvin
All Jonkman Microblog content and data are available under the