I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang stdlib.
This makes your protocol difficult to audit: someone concerned about potential attacks can't just look at your protocol in isolation, but has to factor the underlying protocol state machine into the security of your transport encryption protocol.
OK, so I'm not understanding why isn't a 1-to-1 message, nor why DTLS isn't an option here.
> I guess it depends on your definition of roll your own. We didn't invent AES-GCM or implement it. We are using the implementation shipped with the Golang stdlib.
You need to read better. I didn't say "crypto primitives", I've said "crypto _system_". That includes everything, including primitives, key management, authentication, replay (which means your application protocol is now part of the crypto system, not a good sign), field concatenation for singing/hashing, &c.
The most important thing is that when your improvised system fails, you will more-than-likely never know and it'll never cause any errors.