@mariusor@metalhead.club
@mariusor@metalhead.club avatar

mariusor

@mariusor@metalhead.club

Mostly a programmer.

Implementing #ActivityPub in the #Go programming language.

Current projects:

  • #GoActivityPub - a library to use ActivityPub in Go.

  • #FedBOX - a generic ActivityPub service supporting the client to server API.

  • #brutalinks - a link aggregator inspired by (old) reddit, hacker news and lobste.rs built on top of FedBOX.

  • #oni - a single user ActivityPub server with minimal fuss.

My posts are mostly related to ActivityPub and web development.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

jjb, to mastodon
@jjb@mastodon.social avatar

I'm implementing (slowly) a personal Mastodon/ActivityPub server. Would someone who has done that before please tell me what is wrong with:

https://jeremy.org/.well-known/webfinger?resource=acct:placeholder@jeremy.org
and
https://jeremy.org/@placeholder

...that lookups from other sites don't seem to produce the expected results?

mariusor,
@mariusor@metalhead.club avatar

@jjb not 100% sure if that's the problem, but the subject of the webfinger response is incorrect, you should not have the full resource value in there, just the "preferredUsername@domain.tld"

Also I'm not sure if Mastodon requires the publicKey property to exist for your actor.

mariusor,
@mariusor@metalhead.club avatar

@julian thanx. I was unsure, but I didn't think to double check before. :D

@jjb

gugurumbe, to fediverse
@gugurumbe@mastouille.fr avatar

The scalability problem of ActivityPub is that activities are delivered to all actors, not just active ones. If activities were delivered to only active actors, it would transmit the same number of message as centralized services (and even less if multiple users share the same server).

ActivityPub servers should mark inactive accounts, to indicate that activities should not be delivered to them anymore, until the user logs in again.

mariusor,
@mariusor@metalhead.club avatar

@gugurumbe that should be totally achievable already because servers return 404 when sending activities to inboxes belonging to deleted actors.

The problem is that the sending servers don't internalize the errors into removing those inboxes from all future interactions.

pojntfx, to random
@pojntfx@mastodon.social avatar

Tried out Plasma Mobile 6 on my OnePlus 6T today and whoa it is smooth

mariusor,
@mariusor@metalhead.club avatar

@pojntfx have you tried SailfishOS, some of the UI is reminiscent of it.

mariusor,
@mariusor@metalhead.club avatar

@pojntfx even though it's been like a decade, I still hold hope they're going to make Lipstick open-source at some point.

hrefna, to random
@hrefna@hachyderm.io avatar

"Meta also can’t promise that when you delete a federated post on Threads, it will also get deleted on the other platforms it was shared on"

I mean that's just the fediverse in general, especially with how it works today. Even the ActivityPub spec doesn't make a strong statement on how this is supposed to be handled ("should remove it" from public view is not "must delete it").

mariusor,
@mariusor@metalhead.club avatar

@hrefna I don't follow your math here. I read this as: you sent 2000 Create activities, then you send 2000 Delete activities to the same recipients. EOT

mariusor,
@mariusor@metalhead.club avatar

@hrefna @jenniferplusplus it sounds like what you want is "Undo", not "Delete".

mariusor,
@mariusor@metalhead.club avatar

@hrefna lol. :) I have the excuse that I just woke up, but still...

mariusor,
@mariusor@metalhead.club avatar

@hrefna @jenniferplusplus

I think that's for the simple use case, where you want just the object to be gone. When you want all the "meta data" surrounding an object to be gone also, including its created activity I think that's exactly the way to go.

mariusor, to CSS
@mariusor@metalhead.club avatar

Damn, Firefox does not support computing relative colors with the rgb() function. :(

I don't know if I want to undo the changes I made under the assumption that it does or not.

mariusor,
@mariusor@metalhead.club avatar

@iamdtms nice. I'll try to keep track of it. :)

aliettedb, to random
@aliettedb@wandering.shop avatar

Eastercon here I come!

mariusor,
@mariusor@metalhead.club avatar

@aliettedb which teas are you going to brew with that? :D

mariusor,
@mariusor@metalhead.club avatar

@aliettedb do you have some specific ones? :D (I'm looking for things to search for at my local tea shop)

mariusor, to cycling
@mariusor@metalhead.club avatar

I went out on my fixie today, after almost two years of riding strictly my gravel bike.

That was definitely a change. My body has forgotten all about riding fixed gear, but on the parts I managed to relax, I did some times that I haven't seen in a while. :D

bergmeister, to cycling
@bergmeister@mountains.social avatar

Handy website for Milan - San Remo watchers (or better said, for the ones asking if something is happening yet and they need to start watching):

https://ismilansanremoexcitingyet.com

mariusor,
@mariusor@metalhead.club avatar

@bergmeister the website still says NO, but the things are heating up.

Paul, to fediverse
@Paul@hades.town avatar

Mastodon doesn't seem to like my new AP server, can anyone help me debug the problem?

The actor is @paul

mariusor,
@mariusor@metalhead.club avatar

@Paul sorry to be an ass but: https://dontasktoask.com/

We can't know if we can help if you don't articulate the issue properly.

blog, to fediverse
@blog@shkspr.mobi avatar

I made a mistake in verifying HTTP Message Signatures
https://shkspr.mobi/blog/2024/03/i-made-a-mistake-in-verifying-http-message-signatures/

It's never great to find out you're wrong, but that's how learning and personal growth happens.

HTTP Message Signatures are hard1. There are lots of complex parts and getting any aspect wrong means certain death2.

In a previous post, I wrote A simple(ish) guide to verifying HTTP Message Signatures in PHP. It turns out that it was too simple. And far too trusting.

An HTTP Message Signature is a header which is separate to the message it signs. You might receive a JSON message like this:

{   "actor":   "https://example.com/user/Alice",   "message": "We strike at dawn!"}

How do you know that really came from Alice? You look at the header of the message. It will be something like:

Signature:    keyId="https://example.org/user/Alice#main-key",   algorithm="rsa-sha256",   headers="(request-target) host date digest",   signature="/AJ4Dv/wSL3XE1dLjFHCYVc7AF4f3+Q10G/r8+6cPsooiUh2K3YX3z++Nclo4qKHYr61yu+T4OMqUry1T6ZHmZqmNkg1RpVg=="

We want to check that Alice signed this message with her private key. So we grab her public key given by the keyId.
From there, we do some fancy maths using RSA-SHA256 and conclude that, when you put together the (request-target) host date digest content-type and compare them to the public key, they can only have be signed by the private key. Hurrah!

Did you spot the mistake I made? It wasn't in the maths, or the complex ordering of the data, or the algorithm choice, or some weird Unicode problem.

I made an error in trust.

Take a look at the Signature again.

The keyId is from example.org. But the actor is from example.com.

This message is signed correctly. It is cryptographically valid. But it wasn't signed by the actor in the message!

In this case, the fix is simple. Get the public key from keyId. Then independently get the named actor's public key. If they match, all is well. If not, skulduggery is afoot.

I'm almost tempted to say that you should ignore the provided keyId entirely; the source of truth is the actor's key - and the best way to get that is directly from the actor's profile.

Please explain why I'm wrong in the comments.

  1. You might think the Entscheidungsproblem is hard, but that's just peanuts compared to etc. etc. ↩
  2. Or cake. ↩

https://shkspr.mobi/blog/2024/03/i-made-a-mistake-in-verifying-http-message-signatures/

mariusor,
@mariusor@metalhead.club avatar

@blog you have two problems:

1/ Verify that the HTTP Signature is valid, and as Evan told you some time ago: you should always use the key in the header signature for that.

2/ You need to verify that the Activity actor is the same as the actor that owns that key.

In my opinion trying to simplify this is incorrect and you should always treat them as separate steps happening at different stages in the validation process.

mariusor,
@mariusor@metalhead.club avatar

@blog on why they should be different steps: it could be that you want certain actors to be able to effect activities on behalf of other actors.

Think something like, posting on behalf of a Group actor.

Or anonymizing a Flag activity. You put a generic Actor in the Activity and you sign it as the instance Service actor on behalf of a regular user.

It's up to every server/instance if they want to support these things, but they seem pretty useful to me.

hrefna, to fediverse
@hrefna@hachyderm.io avatar

From the standpoint of the principle of least surprise, what would you expect—not in terms of mastodon's implementation, but in general—the difference would be between:

  • to: as:Public
  • cc:as:Public
  • audience:as:Public

Are they identical, would you expect these to manifest different behaviors? Which would you view as correct?

mariusor,
@mariusor@metalhead.club avatar

@hrefna first two I treated as "this activity needs to go in all the local inboxes that the server knows about". I never used (or seen used) the third.

On another note I also use the presence of the public namespace in the recipients list as a way to allow public access to objects in collections, which could be said that can be better served by this third option.

mariusor,
@mariusor@metalhead.club avatar

@jenniferplusplus @hrefna I mean, the spec specifically invents this usage for the public namespace:

https://www.w3.org/TR/activitypub/#public-addressing

Note "addressing" in the verbiage, which to me implies the To/CC/Bto/BCC properties not "audience".

fentiger, to random

Oh, joy: it turns out that Go's net/url package doesn't understand that DID URLs can have paths.

Parsing "https://example.social/path/to/object" gives me a useful result:

&url.URL{<br></br>    Scheme:"https",<br></br>    Opaque:"",<br></br>    Host:"example.social",<br></br>    Path:"/path/to/object",<br></br>    [...]<br></br>}

But parsing "did:ap: key:z6abcdef/path/to/object" gives me this:

&url.URL{<br></br>    Scheme:"did",<br></br>    Opaque:"ap:key:z6abcdef/path/to/object",<br></br>    Host:"",<br></br>    Path:"",<br></br>    [...]<br></br>}

So I need some kind of wrapper to detect DID URLs and parse the paths out of them. That's easy enough, I suppose, but then I need to actually use that wrapper, in all the relevant places...

#ActivityPub #FediDev #BangHeadHere

mariusor,
@mariusor@metalhead.club avatar

@fentiger I think the RFC shows something like this for how URIs w/o authority get parsed to components:

https://datatracker.ietf.org/doc/html/rfc3986#section-3

mariusor,
@mariusor@metalhead.club avatar

@fentiger and the net/url documentation expresses the problem directly in the URL section:
> URLs that do not start with a slash after the scheme are interpreted as:
>
> scheme:opaque[?query][]

https://pkg.go.dev/net/url#URL

thomas, to random German
@thomas@metalhead.club avatar

Feierabend bei der @zeroiee

Prost! 🍻

mariusor,
@mariusor@metalhead.club avatar

@thomas @zeroiee a strong resemblance to the inhabitants of the Pointed Heads kingdom from "The Point" movie. :P

thisismissem, to fediverse
@thisismissem@hachyderm.io avatar

TIL: ActivityPub reinvented a concept when it comes to OAuth 2.0, and rather than just recommending usage of OAuth 2.0's Authorization Server Metadata endpoint, some of the information became embedded in Actor objects for some reason.

I'm proposing the oauth* endpoints be deprecated: https://github.com/w3c/activitypub/issues/427

mariusor,
@mariusor@metalhead.club avatar

@thisismissem @jenniferplusplus why can't authentication be per actor and not per instance? I enjoy having personalized auth end points for each actor instead of a global one per instance.

mariusor,
@mariusor@metalhead.club avatar

@thisismissem I would agree that the oauth authorization/token endpoints are insufficient, but instead of removing them in favour of a discovery mechanism that has nothing to do with ActivityPub we should come up with a better way to integrate authorization options within the spec. I don't think that deprecation and removal without a valid in-spec alternative is a solution.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • provamag3
  • kavyap
  • DreamBathrooms
  • everett
  • magazineikmin
  • InstantRegret
  • ngwrru68w68
  • Youngstown
  • mdbf
  • slotface
  • vwfavf
  • tacticalgear
  • thenastyranch
  • rosin
  • megavids
  • osvaldo12
  • ethstaker
  • GTA5RPClips
  • khanakhh
  • Durango
  • tester
  • normalnudes
  • cisconetworking
  • modclub
  • cubers
  • anitta
  • Leos
  • JUstTest
  • All magazines
    •