Notices by FenTiger (fentiger@zotum.net)
-
Embed this notice
@silverpill There does seem to be a general feeling that nothing can be considered legitimate until a Task Force has set up a monthly voice call to bestow their approval on it.
-
Embed this notice
@silverpill
using either eddsa-jcs-2022 or mldsa44-jcs-2024
Is this the first implementation of a post-quantum scheme?
Right now eddsa-jcs-2022 is "RECOMMENDED" by FEP-8b32. Should ML-DSA be "RECOMMENDED" too?
-
Embed this notice
@silverpill Yes, I think there are reasons to want to do this even in a pure P2P setup - such as having one copy on a mobile device for portability, and another on a home device as a backup in case you lose your phone.
Agreed that it's worth looking at Iroh - even if it's not useful in the long term, it'll be worth trying to work out what the dependencies on HTTP actually are, and what it'll take to separate ActivityPub from its transport more generally.
-
Embed this notice
@silverpill If you're doing nomadic identity then an actor's data might be replicated across multiple network nodes. Presumably they'll all need their own Iroh keys, rather than being able to reuse the actor's did:key for all of them?
-
Embed this notice
@silverpill Have you (or anyone) given any thought to what happens if you use a dereferenceable DID method (eg did:web)?
This would allow multiple public keys to be valid at once - meaning that multiple servers can all do server-side signing without needing to share a private key.
It also means that keys can be rotated and/or revoked - potentially causing old signatures to become unverifiable.
-
Embed this notice
@silverpill ActivityStreams allows @context to be missing, too:
When a JSON-LD enabled Activity Streams 2.0 implementation encounters a JSON document identified using the "application/activity+json" MIME media type, and that document does not contain a @context property whose value includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition, the implementation MUST assume that the normative @context definition still applies.
-
Embed this notice
Is there any information anywhere on how the Flag activity is used in practice?
As ever, the spec only tells me that it exists; it doesn't say anything about what it contains, where it gets delivered to, how the recipient processes it, etc.
Maybe I could find out more by setting up some test instances and experimenting with it, or by trying to trawl through various repositories to find the relevant source code - but it seems a lot quicker to just ask.
#ActivityPub #ActivityPubDev #FediDev #FediDevs
-
Embed this notice
@silverpill Do you have to double-knock every time? Can't you cache the result when a POST succeeds, so you know which signature method to use next time you deliver to that instance?
-
Embed this notice
"Servers SHOULD implement NodeInfo..." seems a bit strong, especially considering that some people are quite strongly opposed to it. Is this really a SHOULD? Or would it be better to write a paragraph or two about the pros and cons, and let implementers decide for themselves?
Would it be worth recommending that implementers provide a config option to allow NodeInfo to be switched on and off by the instance admin?
Should there be a recommendation that "Consumers SHOULD NOT assume that any given Fediverse site will implement NodeInfo"?
I've seen code out there that uses a NodeInfo hit to decide which auth protocol to use for cross-instance login. I personally don't like this approach and would prefer not to encourage people to use designs like this.
-
Embed this notice
+1 for not sending private keys over the wire. I'm no expert, but I feel a lot more comfortable with this design.
-
Embed this notice
Today I had a quick go at working out how Hubzilla handles permissions for media files.
I've been meaning to do this for a while, to work out how it relates to OpenWebAuth authentication (as described in FEP-61cf), but unless I'm missing something (very possible), it's an entirely separate mechanism.
Summary: it's based on bearer tokens / capability URLs. Each post gets given a random token, and that token grants access to any media files which are attached to it. If you're allowed to view the post, the URLs that it contains grant you the capability to download the attachments, too.
When a post is created:
When a post is encoded to ActivityPub:
Presumably this happens when it's rendered to HTML, too, but I couldn't find that bit.
When a media file is requested:
Pretty simple really, though it took a bit of grepping and guesswork to find all these pieces, and I'm not sure I've found all of it.
#ActivityPubDev
-
Embed this notice
@silverpill Well, in my (sketch of a) design, things like sharedInbox and proxyUrl point at the specific server that's hosting the clone, rather than being common to all the clones (and the oauthAuthorizationEndpoint and such are best found via different mechanisms entirely).
I'll readily admit that there are other possible ways to build it, though.
-
Embed this notice
I would vote against putting it in endpoints, personally, because endpoints is "typically server/domain wide" and is allowed to be a link rather than a nested object, while gateways should be considered to vary from actor to actor, because two actors might be cloned to different sets of servers.
-
Embed this notice
This was my experience too.
It also doesn't play very well in practice with JCS canonicalisation, as used by FEP-8b32 signatures: #^https://zotum.net/channel/fentiger?mid=d9557d63-a9e5-4bba-a39d-e2ee785def42
Trying to treat messages as "JSON-LD first" has taken me a very long way down a blind alley, and cost me a lot of time.
:(
-
Embed this notice
@silverpill
How does it check that the user is logged in? Does it present a login form?
It checks whether the user has a session cookie. Hubzilla doesn't show a login form here; it could, but that wouldn't work so well for eg image fetches.
And then, after login, which instance generates activities?
FEP-61cf only covers authenticating the user. It doesn't tackle the question of what happens when the now-authenticated user writes a post. How should that post federate outwards, in such a way that other instances can trust it? I don't know how Hubzilla approaches this; maybe @Mario Vavti can comment.
-
Embed this notice
@silverpill That'll do - thanks.
I'm sure I saw some discussion relating specifically to collections - but maybe it wasn't in an FEP.
-
Embed this notice
Is there an #FEP which covers adding the attributedTo property to collections?
#ActivityPub
-
Embed this notice
Announcing FedIAM 0.1.0 - Sign in with a Fediverse account!
Suppose you want to allow people to log in to your web site. How will they identify themselves? With a username and password? We've all got far too many of those already, and they're not even particularly secure. Perhaps with a Google or Facebook account? That's a lot easier, but do we really want to allow these companies even further into our lives?
FedIAM is a research project which aims to offer an alternative: using Fediverse and IndieWeb protocols, visitors can log in using any one of thousands of small, independent networks run by ordinary people - or even using a provider that they host themselves, independently of any outside influence.
Now available as open source!
#^https://codeberg.org/FenTiger/FedIAM
-
Embed this notice
@silverpill Good question. Quick, shallow answer: this is just a login system, not an #ActivityPub instance. It could certainly be used in front of an ActivityPub instance, though, and in that context, it's definitely worth thinking about. I don't have any concrete answers, but off the top of my head:
The simplest option would be to create a new local actor, and use this purely for login. Sometimes this is the only option - IndieAuth and the native OIDC mode can both work without the existence of an AP actor at the IdP end.
Another option would be to pair it with AP C2S. The OAuth2/OIDC based modes can provide an access token as well as an identity; this could be used to authorise the RP to connect back to the IdP and post using C2S. This would take a bit of standardisation work, but not a lot; my impression is this would be fairly easy to build.
What if the user has a FEP-ef61 nomadic actor? Sending the private key from the IdP to the RP is probably not a very good idea, but perhaps the IdP could expose an access-controlled endpoint to generate a signature on the user's behalf. With this method the RP would construct an object with attributedTo set to the user's nomadic actor ID, request a signature from the IdP, and then distribute the object however it chooses. (In this case, perhaps the IdP should get to choose the new object's ID too, at which point this starts to look a lot like a variant of C2S.)
-
Embed this notice
@silverpill Yes. It lets you log in using an existing account rather than having to register a new one - but in a "Fediverse compatible" way, without any of the technical and social problems which come with using a Big Tech provider.
It can also (in some, admittedly limited, circumstances) recognise your login session automatically, without having to actually enter your ID every time you click from one site to another.
Statistics
- User ID
- 238890
- Member since
- 29 Jan 2024
- Notices
- 26
- Daily average
- 0
FenTiger
All GNU social JP content and data are available under the