ActivityPub <=> email bridge?

ActivityPub <=> email bridge?

[Eric Wong]

Is it worth the effort?

Something tells me that if ActivityPub reaches high-enough
adoption levels; it'll have to deal with a spam problem that
email folks have been dealing with for decades, too.

So ActivityPub seems like a duplicated effort as far as it's use
for messaging for software development goes...

Re: ActivityPub <=> email bridge?

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> Is it worth the effort?

Maybe...

> Something tells me that if ActivityPub reaches high-enough
> adoption levels; it'll have to deal with a spam problem that
> email folks have been dealing with for decades, too.
> 
> So ActivityPub seems like a duplicated effort as far as it's use
> for messaging for software development goes...

Still true, but it seems to have caught on, lately...

If we manage to try this, it'll be using AP as a transport layer
and still requiring plain-text and RFC5322 (or 822/2822) plain-text
messages compatible with git-am.

That would allow SpamAssassin or similar to perform spam
filtering w/o modification.

Allowing markup or images from arbitrary posters is a nightmare
in terms of spam, phishing and illegal content, though; so
normal mailing list etiquette still applies.

Re: ActivityPub <=> email bridge?

[Konstantin Ryabitsev]

On Tue, Mar 07, 2023 at 10:12:10PM +0000, Eric Wong wrote:
> > Something tells me that if ActivityPub reaches high-enough
> > adoption levels; it'll have to deal with a spam problem that
> > email folks have been dealing with for decades, too.
> > 
> > So ActivityPub seems like a duplicated effort as far as it's use
> > for messaging for software development goes...
> 
> Still true, but it seems to have caught on, lately...
> 
> If we manage to try this, it'll be using AP as a transport layer
> and still requiring plain-text and RFC5322 (or 822/2822) plain-text
> messages compatible with git-am.

I'm not sure about the bridge, but I would very much welcome ability to
archive activitypub messages in a public-inbox archive, with full threading.

> That would allow SpamAssassin or similar to perform spam
> filtering w/o modification.
> 
> Allowing markup or images from arbitrary posters is a nightmare
> in terms of spam, phishing and illegal content, though; so
> normal mailing list etiquette still applies.

Perhaps it's possible to allow attachments from specific instances, but the
default for any federated content is just plaintext content?

-K

Re: ActivityPub <=> email bridge?

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Tue, Mar 07, 2023 at 10:12:10PM +0000, Eric Wong wrote:
> > > Something tells me that if ActivityPub reaches high-enough
> > > adoption levels; it'll have to deal with a spam problem that
> > > email folks have been dealing with for decades, too.
> > > 
> > > So ActivityPub seems like a duplicated effort as far as it's use
> > > for messaging for software development goes...
> > 
> > Still true, but it seems to have caught on, lately...
> > 
> > If we manage to try this, it'll be using AP as a transport layer
> > and still requiring plain-text and RFC5322 (or 822/2822) plain-text
> > messages compatible with git-am.
> 
> I'm not sure about the bridge, but I would very much welcome ability to
> archive activitypub messages in a public-inbox archive, with full threading.

*shrug* email messages may be able to reach a wider audience via AP.

> > That would allow SpamAssassin or similar to perform spam
> > filtering w/o modification.
> > 
> > Allowing markup or images from arbitrary posters is a nightmare
> > in terms of spam, phishing and illegal content, though; so
> > normal mailing list etiquette still applies.
> 
> Perhaps it's possible to allow attachments from specific instances, but the
> default for any federated content is just plaintext content?

Yes, basically anything acceptable to the existing mail community.

I realize sometimes people will need to post photos of failed
boot attempts, so I think those should be federated, too[1] but
absolutely NOT displayed by default in any UI.

[1] especially if they can be fetched via git