[Feature] Shouldn't there be spoof and temporary Links and IDs?

[COALROCK8642]

Is there an existing request for feature?

• I have searched the existing issues

What feature would you like?

Why I have to share my direct account number? just to even invite?
"the best policy is one that is not dependent of outside"

Shouldn't every link and IDs this app requires dies out after sometime? probably mistakenly repeat (but way above character string will make almost impossible clash for one's lifetime, but this too leave trace as it's uniqueness.)

I want;

1. Complete anonymous and spoof-able links as method of sharing.
2. Decision (by developers) to make so anonymous no one even knows whats going on?
3. Re-circulation of IDs to confuse but also avoid getting traced.

Anything else?

Just sharing my ID is kinda killing purpose; so better get changing IDs.
Why? Because, if you don't integrate, others will keep doing some type of DDOS (well i'm not much in coding and tech.)

Well IRL with features exist, but kinda old and maybe even upgrade in future.

[Ryu945]

The developers mentioned before that only an admin can invite the way the code is setup. It is why I suggested before that invite links should be createable as a lowest permission admin. I don't know if anything has changed since then.

[KeeJef]

So, for the temporary Account ID part of this issue, it’s a duplicate of #181, which was closed because the goal was to do multi-account #756 first and see if people still wanted temporary IDs after that, since multi-account would allow users to switch between IDs.

The group invite part of this is a duplicate of #505 and #102.

The problem with temporary Account IDs, which you give out to new people you want to contact you, is that Session has to keep track of these IDs, and it increases the number of swarms you need to poll to receive new messages. Since each temporary ID will likely have a different swarm that stores its messages, this means if you have 100 contacts on Session who added you with a different ID, Session now needs to poll 100 different swarms regularly. There have been thoughts about a sort of unified poll where you would build a path like client -> hop1 -> hop2 -> hop3, and then hop3 sends the request to 100 swarms on your behalf and returns the unified response. However, that would take some time to build. Although it’s a problem Session already faces since each closed group typically exists on a different swarm, although it’s a relatively smaller problem since users typically have fewer closed groups than one-on-one contacts.

Group invite links are tricky as well since, with the way groups are designed, for a user to be invited, the admin needs to know their Account ID. Communities are supposed to be the solution if you need groups that are joinable via invite, but it could be a good idea to review this after the release of updated groups.