@evan thank you!

@hongminhee Well, after the issues with the given ActivityPub "OAuth example", I looked up @fedify /vocab … In all the actor types like https://github.com/fedify-dev/fedify/blob/main/packages/vocab/src/person.yamlthe following properties would be missing [if the official OAuth demo should work] : grant_types_supported: ['authorization_code'],response_types_supported: ['code', 'code token'], code_challenge_methods_supported: ['S256'], token_endpoint_auth_methods_supported: [ 'client_secret_basic'// optional/*, 'private_key_jwt'*/], token_endpoint_auth_signing_alg_values_supported: ['RS256', 'ES256'], client_id_metadata_document_supported: true, optionalscopes_supported and ui_locales_supported:---anyway:I believe it is just misleading because of the order of querying the server and the actor description.I would expect it to meet the spec and pull above properties from the server wide .well-known oauth and just the endpoints from the Actor …#ActivityPub #OAuth

@Tempest Oh, that's surprisingly nice!

I may be missing something, so please correct me: I think we already have authenticated messages and message repudiation. When you decrypt an MLS message, it could only have been encrypted by someone with the group key, and the MLS structure tells us specifically WHICH group member sent the message. However, this proof doesn't extend past your own device. You can't really export that cryptographic state out of your own machine because MLS has already thrown away the keys that bootstrapped that state to begin with. This is the issue facing the trust and safety folks who want to require some sort of message reporting system in E2EE messages. Screenshots aren't enough. So, they're looking at some kind of message hashing feature that could prove the contents of a message. It seems like we have a case of mutually-exclusive requirements. We can't build both message repudiation AND message reporting in the same conversation. It's likely that any solution will need to be build as some kind of extension mechanism, where group originators choose the specific features within that group.

Night. #fedicon

@ReclaimedComputing The plan is for the initial supported device will be the successor to the Motorola Signature (2026). It will be more time before we can add more devices since we need the devices to add support for MTE, secure element features and long term updates. Other flagships are likely going to be the first ones supported. We can work our way down from there once other devices meet our requirements.We'd still like to keep supporting new Pixels too so we have 2 choices instead of 1.

I didn't receive it.

@weekinfediverse wow we're tracking shoot now, that's awesome

@phillycodehound@indieweb.social thank you! Love talking with everyone

@MastodonEngineering@mastodon.social @shlee@aus.social @MOULE@mastodon.moule.world *​:boo:​-reacts mastodon anyway*

There are so many dead instances. Some of them are federated widely, then got abandoned, domain expired and got taken by something like online casino. That would be useful entrypoint for evildoers, maybe allowlists should be linted from time to time