delete the message enevelop here and start using the cwtch one
there's functionality gate stuff here right? port to the cwtch version
I think we should hold off on this for now. There is already quite a bit of complexity in this release and it doesn't make sense to roll in another layer of refactoring. I think it would probably be better to slowly port these in Cwtch over time (e.g. next on the agenda is thinking about hybrid groups which will touch on invitations and overlays and doing the refactoring of that code then makes more sense).
> delete the message enevelop here and start using the cwtch one
> there's functionality gate stuff here right? port to the cwtch version
I think we should hold off on this for now. There is already quite a bit of complexity in this release and it doesn't make sense to roll in another layer of refactoring. I think it would probably be better to slowly port these in Cwtch over time (e.g. next on the agenda is thinking about hybrid groups which will touch on invitations and overlays and doing the refactoring of that code then makes more sense).
sarah
dan
I think we should hold off on this for now. There is already quite a bit of complexity in this release and it doesn't make sense to roll in another layer of refactoring. I think it would probably be better to slowly port these in Cwtch over time (e.g. next on the agenda is thinking about hybrid groups which will touch on invitations and overlays and doing the refactoring of that code then makes more sense).
I guess to me having dual implementations seems like more complexity as future interversions might miss one and be subtly bugged?
WIP: filesharingto filesharing 2 years agoDrone Build Status: success
https://build.openprivacy.ca/cwtch.im/libcwtch-go/79
495c4390c7into trunk 2 years ago