Hi,

I sometimes find it useful to re-share notes, which isn't possible at the moment in Microblog.pub. I haven't looked too deeply, but as boxes.send_announce assumes the announced object is an inbox_object it will eventually fail trying to fetch the local actor.

It looks like that function could check for an outbox_object first, though there may be knock-on effects?

Or perhaps it's intentional to leave this feature out? I suppose it could be reasonably perceived as spammy to re-announce your own posts.

Curious about people's thoughts on this.

Thanks -- I think it's a minor enough contribution!

That, and I don't have git email set up :) I'm happy for you to make a commit.

Hi,

I noticed the image_url field doesn't seem to be listed in the docs. It might be useful to add it and also describe how the profile fields are used.

Suggested diff below.

Thanks, Aonrud

diff --git a/docs/user_guide.md b/docs/user_guide.md
index 6df4859..3e10057 100644
--- a/docs/user_guide.md
+++ b/docs/user_guide.md
@@ -25,9 +25,10 @@ As these two config items define your ActivityPub handle `@handle@domain`.
 
 You can tweak your profile by tweaking these items:
 
- - `name`
- - `summary` (using Markdown)
- - `icon_url`
+ - `name`: The name shown with your profile.
+ - `summary`: The summary or 'bio' part of your profile, written in Markdown.
+ - `icon_url`: Your profile image or avatar.
+ - `image_url`: This provides a 'header' or 'banner' image. Note that it is not shown by the default Microblog.pub templates. It will be used by Mastodon (which uses a 3:1 ratio image) and Pleroma. Pixelfed and Peertube, for example, don't show these images by default.
 
 Whenever one of these config items is updated, an `Update` activity will be sent to all known servers to update your remote profile.

That log suggests you haven't changed the URL that's causing the original issue. Did you edit app/ldsig.py? If you're using Docker you may need to rebuild the image as well.

Same problem here. Does _options_hash need to depend on that context URI, or is there an obvious alternative? I might have misunderstood, but I thought the context URI functioned like a namespace ID rather than requiring an active page?

Anyway, sorry I can't add more, except to confirm the issue, though presumably it affects all installs.

I get it -- I thought the webfinger was just to ensure the servers were aware of each other. Setting also_known_as to the ID URI works; Mastodon has accepted the move now.

A note for anyone coming across this issue: if you add a redirect in Mastodon and then later want to move, it seems you have to turn off the redirect first, or it will give the error "[ID] is the same account you have already moved to".

Thanks ~tsileo!

Ah, sorry, that's a mistake in my post. I did set also_known_as to the mastodon handle. I just checked the JSON response from the root URL and it does contain "alsoKnownAs": [ "me@mastodon.social" ], so I guess the issue is on Mastodon's end. I saw some bug reports about caching on their end, but they seemed to be resolved and I had waited a couple of days, but I assume that must be the issue.

Thanks for your help! Apologies for the unnecessary ticket.

Aonrud

Hi,

I'm trying to use Mastodon's move feature to move fully over to Microblog.pub.

Mastodon says that the microblog.pub account is not an alias of the Mastodon account. I have set also_known_as = "me@microblog.example.com". Am I right in guessing Mastodon is looking in the webfinger response for the alias? It isn't listed in the alias part of the JSON response.

I'm not sure if this is a bug or a setup issue on my side. The webfinger aliases are URIs, so perhaps Mastodon is looking somewhere else for the acct format?

Thanks, Aonrud

That was quick! That seems to solve it, thanks. I'm not entirely sure why Mastodon is requesting that account url, but everything is displaying properly with the webfinger_domain, so it works correctly anyway.

Many thanks for your help.

Aonrud

Thanks -- happy new year to you too!

I don't see a new commit, but I've been experimenting with editing the line above to use the webfinger_domain. That makes the correct webfinger URL work (i.e. example.com/.well-known/webfinger?resource=acct%3Ame%40example.com ), but my tests with Mastodon are now giving errors.

As I understand it, the remote follow link will just redirect to, e.g., mastodon.social/authorize_interaction?uri=https://microblog.example.com, at which point Mastodon will perform its lookups. However, I'm now getting the message "Unfortunately, there was an error looking up the remote account" on Mastodon's side.

I can see a 404 request to microblog.example.com/.well-known/webfinger?resource=acct%3Ame%40microblog.example.com in the uvicorn.log with a Mastodon user agent, but I don't know where it's getting that account name from. I assume it's looking it up against the given URI somewhere and getting the wrong account name, but I can't see any obvious place where this is being set in the code.

Any thoughts? I'm not sure if it's a setup issue on my end, or if that account name is being incorrectly set somewhere in Microblog.pub.

Thanks again,
Aonrud