Papa Dragon a partagé un commentaire sur cette publication/conversation

Streams

Tue, 05 Nov 2024 08:39:58 +0100 de Y

Papa Dragon a écrit la publication qui suit Tue, 05 Nov 2024 08:39:56 +0100

Hi all remaining @!Streams enthusiast,

I've noticed that during the last few days my Streams website are getting a lot slower to load the Stream (and pubstream). Only unusual thing I found in the logs is this:

2024-11-05T06:59:01Z:LOG_WARNING:9515b791a8:Router.php:160:__construct: Module {1} not found.
2024-11-05T06:59:01Z:LOG_INFO:9515b791a8:Router.php:161:__construct: index.php: page not found: /%7B1%7D ADDRESS: 2a01:e9a:bf8:4f0:9af5:1fb1:de0b:8509 QUERY: req=/%7B1%7D
2024-11-05T06:59:02Z:LOG_WARNING:9515b791a8:Router.php:160:__construct: Module {1} not found.
2024-11-05T06:59:02Z:LOG_INFO:9515b791a8:Router.php:161:__construct: index.php: page not found: /%7B1%7D ADDRESS: 2a01:e9a:bf8:4f0:9af5:1fb1:de0b:8509 QUERY: req=/%7B1%7D

The IPv6 address that appears in these lines belongs to the computer I use to visit the website. I really don't know if this could be related to the pages taking ages to load.

@Papa Dragon

Mike Macgirvin 🖥️

Tue, 05 Nov 2024 08:45:27 +0100 de Y

Somewhere in the javascript is a "sprintf" thingy that uses numbers in parens in a template. And some browsers try to "pre-fetch" the template because it looks like a URL.

It's an annoyance, but is harmless.

Papa Dragon

Tue, 05 Nov 2024 09:31:45 +0100 de CaseLibre

Also, I noticed in my logs that some messages related to a no longer existing account keep popping:

2024-11-05T08:21:35Z:LOG_INFO:377212232f:Webfinger.php:37:exec: fetching resource: https%3A%2F%2Fmastodon.sdf.org%2Fusers%2FTomCox from mastodon.sdf.org
2024-11-05T08:21:36Z:LOG_INFO:377212232f:Activity.php:124:fetch: fetch: https://mastodon.sdf.org/users/TomCox
2024-11-05T08:21:36Z:LOG_INFO:377212232f:Activity.php:149:fetch: fetch_actual: https://mastodon.sdf.org/users/TomCox
2024-11-05T08:21:36Z:LOG_INFO:377212232f:Url.php:224:get: error: https://mastodon.sdf.org/users/TomCox: 
2024-11-05T08:21:36Z:LOG_INFO:377212232f:Activity.php:210:fetch: fetch failed: https://mastodon.sdf.org/users/TomCox
2024-11-05T08:21:36Z:LOG_INFO:377212232f:network.php:93:http_status: inbox:403 Permission denied

This comes back nearly every minute while user https://mastodon.sdf.org/users/TomCox does not seem to exist. Is there any way I can read of those?

Mike Macgirvin 🖥️

Tue, 05 Nov 2024 10:14:02 +0100 dernière modification : Tue, 05 Nov 2024 10:24:38 +0100 de Y

Only way I know to eliminate it is to de-federate with Mastodon. I mentioned this a week or so ago. Threads does the same. It's kind of insidious because they send a signed Delete/Actor activity. Before we can process the Delete, we need to check the signature. And to check the signature we need their public key; which was deleted on their own instance along with their account.

We optimise this a bit, but could potentially optimise it further and not even try to fetch the key if we don't have it stored locally. Nothing to delete. This would improve things a bit more.

Jupiter Rowland's (streams) outlet

Wed, 06 Nov 2024 22:19:43 +0100 de Streams at els Mussols

It's kind of insidious because they send a signed Delete/Actor activity. Before we can process the Delete, we need to check the signature. And to check the signature we need their public key; which was deleted on their own instance along with their account.

I'm genuinely surprised it doesn't break on their side already. Or maybe it does, but nobody has noticed it yet.

Marcus Rohrmoser 🌻

Wed, 06 Nov 2024 23:36:57 +0100 de mastodon

Hi @Jupiter Rowland's (streams) outlet @Mike Macgirvin 🖥️ @Streams,
if you - while processing the Delete - get a 410 on the keyId - do you think the actor is deleted (what the delete was supposed to indicate) or not?

What else do you need?

Jupiter Rowland's (streams) outlet

Thu, 07 Nov 2024 08:50:06 +0100 de Streams at els Mussols

@Marcus Rohrmoser 🌻 I'm not a developer or a protocol designer. But I assume that you need the key with which the Delete/Actor activity was signed to verify that the Delete/Actor activity is genuine. The very same key that was deleted immediately after the Delete/Actor activity was sent, although it was still needed.

It's completely asinine to sign something with a key, make it depend on that key and, within a split-second, delete the key again. I seriously wouldn't wonder if Mastodon's performance issues came not only from Ruby on Rails, but also from instances looking for deleted keys all the time.

I mean, sure, in theory, you can assume that if a Delete/Actor activity is signed with a key, it's always genuine even if the key is nowhere to be found. But seriously, that'd enable me to forge a signed Delete/Actor activity with some random key to flag your account deleted in most of the Fediverse and get away with it by intentionally throwing away the key.

So what we actually need is the ActivityPub standard to define how long keys of deleted user accounts must be stored post-deletion so that all Fediverse server software can count and depend on it. And maybe after that period and only after that period, a signed Delete/Actor activity can be assumed genuine even without its key. And we need Mastodon and Threads to adhere to this.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #ActivityPub

Thu, 07 Nov 2024 19:13:53 +0100 de hubzilla

@[zrl=https://streams.elsmussols.net/.well-known/apgateway/did

z6Mkmc3YmgUu5jTyhc6YqC8VjnMwmFtdjFFA45MHTqyBFaA2/actor]Jupiter Rowland's (streams) outlet[/zrl]

intentionally throwing away the key.

Already possible with hubzilla either by mistake, incompetence of bad behaviour

Wed, 06 Nov 2024 20:55:15 +0100 de hubzilla

The need to verify signature may also be problematic with nomadic identity.

Person A creates an account on a hubzilla hub web server. The subsequent channel posts content. The channel/profile has not been exported to the 'channel export' file

Some time in the future. Web server, domain dies. Further time in future, domain is resurrected, new software installed, etc. etc. Person A attempts to create the same channel/profile name. Is able to do so, but the previous channel/profile name still exists within the fediverse.

If understood correctly, there is going to be a conflict with a channel/profile of identical name, but different 'guid' or other attribute that is used to verify identity.

Mike Macgirvin 🖥️

Wed, 06 Nov 2024 21:13:31 +0100 de Y

What we've typically done is grab all known location records for this identity and loop through them until we find one where the public key verifies the current signature. If we do, we'll invalidate any other records with the same hostname. If we don't, we'll fetch a fresh actor record and try again.

Wed, 06 Nov 2024 21:39:55 +0100 de hubzilla

This may explain why it has been observed that content is not being delivered.The extant signature is never going to verify a precedent channel/profile because they were never created at the same time.

If the public key is either never retrieved and/or repeated attempts to collect a new actor record are never successful in actor identity verification.

This could be avoided if the channel/profile creates automatically a public key upon creation, before any content may be published (or connection requests made) before invocation of the channel export file. Something similar to account creation within matrix protocol