FenTiger

Public Key

npub1cswhk5mv83jj8d02jjg62wzdcwf2qavq93d2szgs9l687qk4lm9shsrhpe

NIP-05 Address

fentiger@zotum-net.mostr.pub

Profile Code

nprofile1qqsvg8tm2dkrcefrkh4ffyd98pxu8y4qwkqzck4gpygzlarlqt2lajcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszvfhv9

Publishing to

offchain.pub

relay.damus.io

nos.lol

Author Public Key

npub1cswhk5mv83jj8d02jjg62wzdcwf2qavq93d2szgs9l687qk4lm9shsrhpe

Show more details

Last Notes

2026-10-24 12:12:08 UTC

Visualise your Fediverse / Atmosphere / Social Web identity as a graph! See how your accounts and web presences are related to each other via rel="me" and other discoverable relations: https://glider.mythik.co.uk/
Now with support for ATProto handles and DIDs! Bluesky have added profile page links, so I finally got around to updating this to understand their identifiers.
Original announcement
#FediDev #ActivityPubDev #ATProto

2026-10-17 12:05:10 UTC

If we want a DID method that is "strongly-consistent, recoverable, and allows for key rotation"1 then the options are a central registry or blockchains ... no?
An interesting development from the #ATProto world: a look at how to construct a fully decentralised #DID method using a distributed hash table. I doubt the Atmosphere will adopt it, but it does seem like more or less the kind of thing we need for nomadic identity.
https://nelind.leaflet.pub/3mxyxlwklss2l
#FediDev #FEPef61 #PortableObjects

2026-08-23 19:21:52 UTC

- reply

@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.

2026-08-22 08:56:52 UTC

- reply

@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?

2026-07-21 10:55:22 UTC

- reply

@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.

2026-07-21 09:21:08 UTC

- reply

@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?

2026-07-12 10:33:12 UTC

- reply

@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.

2025-10-08 12:31:33 UTC

- reply

@silverpill I propose the toot:harassable profile flag, to indicate whether the user consents to being harassed on the Internet. Anyone who doesn't want to be harassed can just set it to false.

2025-06-03 16:37:06 UTC

- reply

@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?

2025-05-10 21:58:42 UTC

- reply

"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.

2025-04-23 19:20:15 UTC

- reply

+1 for not sending private keys over the wire. I'm no expert, but I feel a lot more comfortable with this design.

2025-03-23 10:24:37 UTC

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:
Generate a random token for it. Record that the token grants permission to access any attached media files. Store the token to the DB as part of the post.
When a post is encoded to ActivityPub:
Find the associated token and append it to any URLs referring to attached media files
Also do the same for any attachment objects
Presumably this happens when it's rendered to HTML, too, but I couldn't find that bit.
When a media file is requested:
Extract the token from the request. Check that the requester has permission to view the file, including checking whether the token grants permission.
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

2025-03-19 18:24:34 UTC

- reply

@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.

2024-12-21 10:22:23 UTC

#FedIAM 0.2"Release early, release often", they say. Well, I managed one out of two.
I've been continuing to work on my experimental federated sign-on system, FedIAM.
Summary of changes since release 0.1:
Split it into three modules - user interface, IdP and RP - and start to reduce the dependencies between them Support multiple #OIDC clients (not just Kratos) PKCE is now mandatory Take some steps towards supporting #ATProto OAuth (not yet complete)
Discourse DemoThe main highlight of this release: I have integrated FedIAM with a real application, Discourse.
For a slightly more interesting demo than the last one, feel free to try it out at discourse.mythik.co.uk!
To log in to this forum:
Hubzilla/Streams and FedCM users don't need to do anything special - just follow the link, and you'll be logged in! Mastodon and classic IndieAuth users can log in by clicking the "Log In" button and entering their ID to start the flow.
In this setup, Discourse is configured to use FedIAM as an OpenID Connect login service. It's quite crude - some of Discourse's features won't work in this configuration.
It's only a demo. I reserve the right to shut it down and/or wipe the database at any time. Don't post anything on there if you want to keep it.
Other NewsA couple of interesting developments have taken place since the release of FedIAM 0.1 back in August.
Mastodon 4.3 releasedOriginally FedIAM's support for #Mastodon was very patchy, because it relies on some OAuth2 protocol changes which were only available in nightly builds at the time. The Mastodon team have now released these changes as part of version 4.3, so a sizeable portion of the Mastodon network can now log in via FedIAM!
ATProto OAuth2#BlueSky have revealed their design for federated login using #ATProto. This is not supported by FedIAM yet, but I have a basic proof-of-concept implementation of this.
The thing that's interesting about this is its use of Decentralized Identifiers (DIDs). There seems to be a general consensus that DIDs are the future of identity in distributed systems, but to date BlueSky's ATProto login system is the only concrete proposal I've seen that makes use of them. It takes significant work to get from "maybe we could do it like this" to a design which is well-specified enough to implement in an interoperable way; the BlueSky team have put in this effort, and they've done a great job of documenting it, too.
I hope to offer full support for ATProto/BlueSky logins in FedIAM 0.3.

2024-11-25 09:55:55 UTC

- reply

@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.