One thing: now for every user, there is also the temp user. to invite someone, you generate a private key, and send it to them. What if they started using it like a normal identity?

Their application/UI could avoid giving them that option. if they went around that and used the feed as a normal identity anyway, they could do that.

One way to handle this: when the inviter follows the temp identity, they could include in the message some data indicating that the followed feed is a temp feed, and sign that with the temp identity. then application UIs could show on the temp feed's profile page that it is a temp identity created by the inviter, so people know what kind of identity they are dealing with.

Another option: if we had code to detect forked feeds and use that to mean "stop replicating this feed", the inviter could detect when the invite is used and then deliberately fork the temp feed.

What happens with invites that don't get accepted? it would mean you appear to be following a bunch of people who don't really exist. Hmm, I guess there is the proposal to skip requesting feeds which havn't changed, but info about those feeds would have to be lurking around somewhere.

Yes, they would take up resources in the replication. one way to address this: create a user-invites UI, that would list "outstanding invites", and give the user the option to cancel (unfollow) them - with encouragement to do so in order to free up resources. it could also list "accepted invites", which would each have the option to unfollow the temp feed and follow the invitee's own feed. other UIs listing feeds a user follows could be updated to hide the temp identities