One of the proposals ("Erk") reduces the need for users to regularly come online to refresh their vtxos, which is a laudable goal. The other proposal ("Hark") simplifies how Erk's atomic swaps work at the expense of reintroducing "regular refreshes." I like Erk better.

Erk doesn't "technically" reduce the need for regular refreshes, it just outsources them to the server. If a user stays offline for 5 years, the server can just constantly refresh their vtxos for them, deducting a pre-agreed fee each time. I like that. And if the server "doesn't" do the refreshes, the user can either hire a watchtower to rescue their funds or broadcasting their exit txs for them, or they can do it themselves.

In my coinpool implementation, I also tried to improve upon Ark by eliminating the need for regular refreshes. My method was to replace the absolute timelock on user funds with a relative timelock whose 2-week countdown only starts when the admin broadcasts a "notification tx." During the 2 weeks, the user can broadcast his exits txs (or a watchtower can do it for him), but when the time is up, the admin gets the user's funds, just like in Ark.

My hope is that the admin wouldn't need to ever use the notification tx. Instead, I think users should pay a monthly fee to the admin to stay in the coinpool if they are benefiting from it, and my model allows the admin to kick any user(s) out of the coinpool e.g. if they stop paying their bills, so if a user disappears, that seems like a more appropriate remedy in most cases than broadcasting the notification tx, which basically threatens to take everyone's money unless they exit within the next two weeks.

I only think the latter option makes sense if all the "responsive" users have left (e.g. maybe the admin decided not to do it anymore and asked everyone to leave) and there are still multiple unresponsive users, and the admin is getting impatient. Rather than kick each unresponsive user out individually, it's more efficient to give them a final 2-week notice (by broadcasting the notification tx) and then take their money if they still don't come back. Of course, like with Ark, these users can hire a watchtower to rescue them if this scenario arises, or they can broadcast their exit txs themselves.

I'm not sure which method I like better, Erk or my own. But mine has this advantage: it works right now, with no soft fork, and achieves a similar goal, namely, users do not need to regularly come online to refresh their coins. They do need to pay their monthly bill, but since my coinpool supports async payments and uses relative timelocks, I can ease this by repurposing the absolute timelock field: the user can make a series of "bill payment" txs to the admin that are each "absolutely" timelocked til a different month in the future arrives, and send them all to the admin right at the beginning. Now the admin can claim each payment one by one as the months tick by, and the user doesn't need to come online for that because payments in my coinpool are asynchronous. This also incentivizes the admin to keep that user around; until his bill payment txs are all used up, he's a paying customer.

I think the Ark teams should give my coinpool model a closer look. I think it accomplishes without a soft fork a lot of the things they want to accomplish "with" one.