This actually showcases a flaw with BridgeNet I’ll get on fixing when available.
As of right now there’s no way to tell when BridgeNet is started. This means you’re kinda forced to use single-script architecture which is something I encourage you to research, but I’m not going to assume everyone who uses BridgeNet will do this.
So, I think what I’m going to do is make functions such as CreateBridge yield until BridgeNet starts. However, it’s possible that it plays nicely without starting because starting BridgeNet connects to heartbeat and all that. I’m still going to make this functions yield until start because I don’t want completely unexpected behavior in my module 
the code snippet you asked for:
Client
local Object = BridgeNet.CreateBridge("Test")
Object:Connect(function(arg1, arg2, arg3)
print(arg1)
end)
while task.wait(1) do
Object:Fire("Hello", "world")
end
Server
local Object = BridgeNet.CreateBridge("Test")
Object:Connect(function(plr, arg1, arg2)
print(plr, arg1)
end)
while task.wait(1) do
Object:FireTo(game.Players:GetPlayers()[1], "Received: Fire")
end
To answer your second question, the bridges are just connected by string, and you need to call CreateBridge separately on the client and the server. However, if you need to index a bridge that’s already created, you can do .FromBridge(). As of right now, this will return nil if it doesn’t exist, which means I could probably add in a .WaitForBridge() function to make this process easier.
I think one thing I could do is use symbols instead of text indexes, so it would be like
BridgeNet.Start({
[BridgeNet.DefaultReceive] = 60,
[BridgeNet.DefaultSend] = 60,
})
You’re right, plain text keys are easy to forget and get confused (it’s already happened!), but the reason I don’t want to use the order of arguments is because of how difficult it is to change. Say I want to remove the default send and receive options in a year, what happens then? Backwards compatibility breaks.
And thank you! Every bit of support means a lot to me.
