Hi,

This patch enables email notifications to the site owner.  I've been
running it on my instance for the past week or so, and have found it
useful.  It's rudimentary and not ready for merging, but I wanted to get
a temperature check on the feature to determine whether I should carry
the patch locally for my own personal use, or polish it up and propose
it for merging.

Questions:

1. Are email notifications a desired feature?

2. Is this approach (hooking sqlalchemy `Notification` insert)
[message trimmed]

On 2022-11-19 2:42 PM, Alexey Shpakovsky wrote:
> What do you think?

Sounds reasonable to me!  I agree it's a bit hacky to require changes to
the git-tracked supervisord.conf.

On 2022-11-18 11:29 AM, Thomas Sileo wrote:
> I wonder if having `null`/`None` as the `icon` would a better option?
> Did you look at how other software are handling this (and have you tested with at least Mastodon)?
> 
> I am afraid it could break federation with some software expecting the `icon` key to be there.

A reasonable concern!

Microblog.pub instances seem to show the local nopic.png (not the
Mastodon default icon) on mastodon.social users who haven't set an icon.
Fetching the Mastodon actor JSON manually confirms that the "icon" key
is missing entirely for no-icon users, and present for users with an
icon set.  So I think this patch's behavior matches what Mastodon does. 
I've been running it on @noc@doof.net for the past several days, and

If a remote actor has no icon, we show our local default icon.

If we have no icon, we should allow remote instances to show their
default icon, instead of sending ours.
---
 app/activitypub.py       | 12 +++++++-----
 app/config.py            |  2 +-
 app/main.py              |  9 ++++++---
 scripts/config_wizard.py |  5 +++--
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/app/activitypub.py b/app/activitypub.py
index 170811d..3a96e8b 100644
--- a/app/activitypub.py
[message trimmed]

---
 app/config.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/config.py b/app/config.py
index 14bb913..0dc868a 100644
--- a/app/config.py
+++ b/app/config.py
@@ -257,5 +257,5 @@ def verify_csrf_token(
     return None
 
 
-def hmac_sha256():
+def hmac_sha256() -> hmac.HMAC:
[message trimmed]

Useful when app is at a non-root path and we're not handling top-level
/robots.txt requests.
---
 app/templates/followers.html       | 1 +
 app/templates/following.html       | 1 +
 app/templates/login.html           | 3 +++
 app/templates/remote_follow.html   | 1 +
 app/templates/remote_interact.html | 1 +
 5 files changed, 7 insertions(+)

diff --git a/app/templates/followers.html b/app/templates/followers.html
index a5df2bb..dabd049 100644
--- a/app/templates/followers.html
+++ b/app/templates/followers.html
[message trimmed]

Necessary when running at a non-root path
---
 app/actor.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/actor.py b/app/actor.py
index ecf53f1..271b88b 100644
--- a/app/actor.py
+++ b/app/actor.py
@@ -12,6 +12,7 @@ from sqlalchemy.orm import joinedload
 
 from app import activitypub as ap
 from app import media
+from app.config import BASE_URL
[message trimmed]

Misc cleanups following up on previous patches.

Kevin Wallace (3):
  Use BASE_URL when generating {proxied,resized}_image_url
  Add robots meta tags on pages in robots.txt
  Add return type to hmac_sha256

 app/actor.py                       | 5 +++--
 app/config.py                      | 2 +-
 app/templates/followers.html       | 1 +
 app/templates/following.html       | 1 +
 app/templates/login.html           | 3 +++
 app/templates/remote_follow.html   | 1 +
 app/templates/remote_interact.html | 1 +

On Sun, Nov 13, 2022, at 8:39 AM, Thomas Sileo wrote:
> (and I think Firefox is doing "the right thing" :p).

Agreed - Chrome's behavior doesn't protect us from anything, and just makes things more complicated in cases like this.  Hopefully they update the spec to match Firefox.

Follow-up commit looks good!  Good catch on adding it to remote interactions, too.

In Chrome, I get the following when trying to use the remote follow form:

    Refused to send form data to 'https://example.com/remote_follow'
    because it violates the following Content Security Policy directive:
    "form-action 'self'".

It seems some browsers (but notably not Firefox) apply the form-action
policy to the redirect target in addition to the initial form
submission endpoint.  See:

    https://github.com/w3c/webappsec-csp/issues/8

In that thread, this workaround is suggested.
---
[message trimmed]