Signatures are in the spec, but only by name - and we're left swinging in the wind when it comes to implementation and interoperability. And of course that's where everything always goes bloody wrong.
I know (re http sigs), and that is exactly why Mastodon implemented signatures in the payload even though they're not in spec. I was just asking if you were aware, no need to lecture. I doubt anyone is happy that there is no signatures in the spec.
We generate HTTP Signatures, LD Signatures, and magic envelopes. LD Signatures are fatally flawed/worthless and we'll use them if that's all you've got, but we will always prefer a reliable signature method and only validate LD Sigs as a last resort. HTTP Sigs work well, but can only be used to validate a sender - and won't do a thing for validating the author if you're relaying comments downstream.
Curiously Mastodon doesn't sign Follow activities currently, but they do sign posts/comments.
Mike, did you implement signing with LDS? Mastodon did, though it's not really in spec. I assume they will reject anything that isn't signed, but this is guess work. You would probably need to contact Gargron.
Oh hang on - I think Mastodon will answer webfinger requests on URLs, as we also do. So if you want an ActivityPub connection, you can connect to a specific protocol by using protocol: before the thing you want to connect to in the Follow box. In this case activitypub:{{their url}}
Handles aren't used in ActivityPub. If you use the URL you should get an ActivityPub connection.
Mario suggests that Mastodon is failing to import messages we originate (including follow requests), and I don't know what can be done without getting somebody there to investigate. AFAIK our AP messages are legal and conforming (currently). They will go unlawful in the future when we allow AP to cross-federate with other protocols.
I connected my test channel with my Mastodon account, and everything seems to federate just fine. But I have no idea whether I needed to do anything fancy.
It's not too hard to hack a theme together; mostly you just need to create some PHP files denoting what the theme name is, and what the CSS component should be called.
Schemas are preferable if you anticipate having variations of the same theme. Personally, I disable these and try to create single-style themes instead.
The other cool thing is that Hubzilla themes support custom widget layouts. I believe they might also support entirely original widgets written from scratch, but I haven't explored that a whole lot yet.
Clarity is an attempt to get back into Hubzilla theme development. At present, it is the only theme in my repo that will work with the latest versions of Hubzilla. Everything else needs to be updated to work with the latest interface improvements.
The design intent around Clarity is to configure a good basic layout, and polish up Hubzilla's look and feel. Work is ongoing to give the theme some sense of uniqueness.