universe: add server info RPC, check we're not connecting to ourselves

[guggero]

Fixes #350.

[jharveyb]

LGTM, pending the possible change to execute at startup.

[Roasbeef]

Hmm, do we actually want people to be able to hit this?

[guggero]

If we want this simple check to work, then yes, we need users to be able to connect directly without a macaroon and query this info. That's why I chose not to include any sensitive information. Maybe we even need to remove the two counts we have as those issue DB queries. If that is a concern and we just want to use this for the ID, maybe we could rename the RPC to just ServerID?

[Roasbeef]

Maybe we even need to remove the two counts we have as those issue DB queries.

In theory users can already obtain this information if the universe server is open, albeit with even more DB queries.

[Roasbeef]

Hmm, yeah seems simple enough, wondering if there're other alternatives we should consider 🤔

[Roasbeef]

Also fwiw, this isn't the call path that would lead to us adding ourselves, instead it's here:

taproot-assets/tapcfg/server.go

Lines 180 to 201 in 7ab8a57

	federationMembers := cfg.Universe.FederationServers
	switch cfg.ChainConf.Network {
	case "testnet":
	cfgLogger.Infof("Configuring %v as initial Universe "+
	"federation server", defaultTestnetFederationServer)
	federationMembers = append(
	federationMembers, defaultTestnetFederationServer,
	)
	}
	universeFederation := universe.NewFederationEnvoy(
	universe.FederationConfig{
	FederationDB: federationDB,
	UniverseSyncer: universeSyncer,
	LocalRegistrar: baseUni,
	SyncInterval: cfg.Universe.SyncInterval,
	NewRemoteRegistrar: tap.NewRpcUniverseRegistar,
	StaticFederationMembers: federationMembers,
	ErrChan: mainErrChan,
	},
	)

https://github.com/lightninglabs/taproot-assets/blob/main/universe/auto_syncer.go#L105-L118

This'll actually end up skipping this RPC path.

[guggero]

wondering if there're other alternatives we should consider

I thought about it a bit and I think it's not trivial to find out if we are connecting to ourselves just from the URL/domain name. Because what we have configured as our RPC listener port might be completely different from the domain name/port we are given to connect to (due to load balancers and other things inbetween). So I thought this was the simplest approach.
But I'm open to other approaches.

Also fwiw, this isn't the call path that would lead to us adding ourselves, instead it's here:

Yeah, I somehow forgot about that path before. Fixed now.

[Roasbeef]

But I'm open to other approaches.

Hmm, good point about the ports, etc....not sure there's a good option other than this. Only other thing can think of is extending to also support using brontide over gRPC, then we'd have the public key we can check against.

Also if we want a bit more assurance that we won't have to worry about collisions here, then we can sample a [32]byte with the CSPRNG. I think we can run with this for now, then circle back to see if was have false positives in the wild (a bit of extra logging can help us detect that).

In terms of gaming, worst thing I can think of is someone sort of bans a server from connecting to them as they mimic their runtime ID, but then they can already to that by banning the IP itself.

[guggero]

Wouldn't we also need to know the public key of the server when using brontide? Or is there a variant of the Noise protocol where you learn the other side's long-term keys without also doing SPAKE?

I don't worry about collision too much. If there was a collision between my local daemon and the universe, I would just restart my daemon and the collision would be gone.
And I agree about banning, I don't think we introduce any new assumptions regarding that with this approach.

[jharveyb]

LGTM! No strong feeling about if we should leave the DB calls in.

[Roasbeef]

LGTM 🥬

[Roasbeef]

Needs a rebase!