How would the gossip protocol announce channels from a channel factory? I was just listening to SLP59 with Christian Decker. They mainly discussed channel factories. While the construction of multiparty channels and higher order systems (sub channels) being derived from them seems clear 
 and is being described in this paper I wonder how the gossip protocol would have to be adapted so that people would be able to announce such channels? 

Generally there is the necessity to point to a funding tx of a payment channel in order to prevent spamming channel announcment messages and in order to authenticate channels. However with channel factories there is only one large funding tx for the multiparty channel. The sub channels are offchain. 

How would a solution for the gossip protocol look like?
Pretty much everything would stay the same. If you look at the relevant messages channel_announcement and channel_update we have the following formats:

channel_announcement


  
  type: 256 (channel_announcement)
  data:
  
  
  [64:node_signature_1]
  [64:node_signature_2]
  [64:bitcoin_signature_1]
  [64:bitcoin_signature_2]
  [2:len]
  [len:features]
  [32:chain_hash]
  [8:short_channel_id]
  [33:node_id_1]
  [33:node_id_2]
  [33:bitcoin_key_1]
  [33:bitcoin_key_2]
  
  


channel_update


  
  type: 258 (channel_update)
  data:
  
  
  [64:signature]
  [32:chain_hash]
  [8:short_channel_id]
  [4:timestamp]
  [1:message_flags]
  [1:channel_flags]
  [2:cltv_expiry_delta]
  [8:htlc_minimum_msat]
  [4:fee_base_msat]
  [4:fee_proportional_millionths]
  [8:htlc_maximum_msat] (option_channel_htlc_max)
  
  


If you look at this you'll see that the channel_announcement includes a lexicographically sorted list of node and bitcoin signatures and their corresponding pubkeys. This is trivial to extend to arbitrary number of participants by making this list variable in length.

In particular the short_channel_id still refers to the single output that the off-chain contract was opened with, that'd also stay the same.

channel_update may seem a bit more complicated since now there are n*(n-1) possible directions (sender-receiver pairs) this contract can be traversed, whereas in the simple 2 participant channel we just have 2 directions. The direction concept can however be easily extended to just lexicographically rank all sender-receiver pairs and use the index to identify the pair.

It is likely that some of the message formats need to be amended (variable length pubkey and signature lists) and some fields be made explicit (rank index for sender-receiver pair), but the general concept stays the same.