Anybody know what triggers a profile re-fetch in #mastodon ?
-
Robb Knightreplied to Johannes Ernst on last edited by
@J12t The profile info like name, etc is trigger when the instance receives the event (user.updated I think).
As for posts/followers, I’ve never been clear on that.
-
Mike Macgirvin 🖥️replied to Johannes Ernst on last edited byCan't answer that. Will only mention that I would consider it good practice to put an updated timestamp on the actor record, with a separate one on the profile photo and send an Update/(Person,Group, etc.) activity to your peeps when they change.
Probably a good idea to put a timestamp on followers and following as well, but my server has better things to do than try and keep accurate follower counts for the whole known fediverse. We have enough trouble dealing with the thousands/millions/? of Delete/Actor messages whenever anybody from anywhere in the Mastodon galaxy of the fediverse removes an account. -
Johannes Ernstreplied to Robb Knight on last edited by
@robb You mean when it receives an UPDATE activity on the Actor object? But the other instance would only do that if there were an actual follower on the local instance, what about if it only got there because somebody was mentioned etc?
-
Johannes Ernstreplied to Mike Macgirvin 🖥️ on last edited by
@mikedev Well, the fediverse is largely not acquainted with the idea of (eventual) consistency. A problem IMHO but hard to fix at this point.
Would you know this? When you observe DELETEs on Actors, in your experience, were they all sent from the instance that hosted the actor, or are there cases where other instances send it? Like some instance from where the post was reshared and reached an audience the original server didn't know about.
-
Mike Macgirvin 🖥️replied to Johannes Ernst on last edited byIt's possible other instances can send these, and I can't rule them out - however the vast majority are sent by the original instance that hosted that actor. And each one is sent to every site in the known fediverse; regardless of whether they have ever interacted with the actor in question.
While I can see that as one way to ensure that the existence of that particular identity is completely removed from the fediverse, it doesn't really scale.
And to add insult to injury - if the identity is nomadic (I'm working on this now) it will require a bit more nuance - as you aren't removing the identity; but only a particular location for that identity. -
Johannes Ernstreplied to Mike Macgirvin 🖥️ on last edited by
@mikedev How to DDOS the Fediverse in two easy steps: create account. delete account.
-
Johannes Ernstreplied to Mike Macgirvin 🖥️ on last edited by
@mikedev I meant to ask you about your nomadic identity work in the ActivityPub part of universe ... any particular place that I should be following? There is some SSO talk re-emerging in certain quarters and it would be nice to not re-invent the wheel... to me at least
-
Mike Macgirvin 🖥️replied to Johannes Ernst on last edited byThat's what I'm worried about. When (not if) the real spammers start to discover the fediverse and how poorly most projects are defended against comment spam (especially the elephant in the room), there could be tens of millions of these suckers every day - day in and day out.
-
@[email protected] whenever we fetch an actor, we also save the timestamp.
Right now we only update the actor if an update is received, but it would also make sense to also do an update after some pre-determined period, like 30 days, 1 year, etc.
But that's me, not Mastodon.
-
Renaud Chaputreplied to Johannes Ernst on last edited by
@J12t when we receive an Update for this account, and more recently when we receive a new status and the account has not been refreshed in the last 7 days
Add auto-refresh of accounts we get new messages/edits of by ClearlyClaire · Pull Request #26510 · mastodon/mastodon
Mastodon already refreshes accounts in various edge cases but otherwise relies on getting Update activities. This PR schedules an update when processing a new or updated post from a remote account,...
GitHub (github.com)
-
Johannes Ernstreplied to Renaud Chaput on last edited by
@renchap That sounds like a good practice.
-
Mike Macgirvin 🖥️replied to Johannes Ernst on last edited byI'm just implementing FEP-ef61. Since we've already got nomadic identity, most of the architectural issues were fleshed out years ago and it's just a matter of making that work over ActivityPub. There's nothing to follow really. It's all just making DIDs work with the elephant in the room.
There's an opportunity for some overlap with SSO once we've reached critical mass around DIDs, but SSO is a different domain entirely. We're currently using OpenWebAuth (http-signatures+webfinger) for that; and there's no shortage of people who want to build something on OAuth or SAML. You can use a DID as an identity claim in any of these. Tying this identity claim and proof to your current browser session has always been the biggest obstacle (for any possible value of $browser). What data you use as an identity claim is a relatively trivial part of the problem.
I am also looking forward to creating a new generation of my Fediverse Identity Manager based on DIDs rather than rel-me relationships. That's not really SSO but more identity aggregation.
So this is really a 3-headed beast.