Hello Matt,
I spent a part of my working day reading the forum.
I didn't know of any of handler, broker before reading your specs.
They aren't part of the LoRaWan 1.0 specification.
May be they are part of the following one; the 1.1 revision. I don't know, I don't have access to this revision.
I've heard of Join Server which I suppose is part of the LoRaWan 1.1 specification but didn't know about this handler and this broker.
Of course the LoRaWan 1.0 was made for carriers and to distinguish the customer realm from the carrier one.
But what is possible to do in a P2P environment like Internet?
That's the question that you tried to solve.
At present time I don't know if your solution is the best for everybody: users of course but also you as maintainers and operators.
I can't evaluate right now if there is or there's not any flaw in the concept.
Did you try to make a formal evaluation of flows?
I think it's a very good thing to establish a QM flow as soon as possible in the exchange but would the user be able to use it and will this QM topics be able to absorb any type of data coming from anywhere
in the world without data crashing other ones?
I have to think about it a little more and ask more questions in the forum.
BTW, I can't see in your architecture the mean to reach nodes from application server/handler (if I want to change the configuration of my sensors for example).
LoRa, whatever the class may be, has a mecanism to reach the mote.
It would be very convenient not to cancel this opportunity.
Eventually, I'd suggest not to be too far from the standard in order to avoid hard updates in the future.
As you are a member of the LoRa Alliance, I'd advise you more to keep pressure onto the alliance in order to promote an alternative model, if any, rather than inventing it.
Thx a lot,
db