@elavoie

Here's my in-order feedback from a single read-through. Disclaimer: I'm in the process of rereading Walkaway right now, so both the paper contents and my remarks feel very "default" (in the Walkaway sense) to me right now, and hence rather negatively connotated.

• "to redecentralize major Internet services[,] often using" more comma
• section 2.1 contributors, last sentence: "boundary by reserving updates to other contributors [that meet the contribution requirements of those updates]."
• "Producers are similar to regular knowledge producers, such as software developers, bloggers, writers, video producers, etc." Unclear what "regular" is, only the next sentence makes clear what is being contrasted here.
• "because the dominant cost in a peer-to-peer system is developer’s time" citation needed =P
• "For the special case of software updates from developers of the system, the same contribution gives both the ability to push a contributor own’s updates and pull the latest developer updates." This was not enough for me to understand why this is a special case that requires specific treatment.
• 2.3, time-based subscription: reading the name, my mind immediately jumped to the problem of any global notion of time requiring concensus finding and introducing centralizing (or at least global-singletonalizing) system components. And sure enough, suddenly and nonchalantly a blockchain pops up for the first time (excluding the abstract), as if it was no big deal. All of this makes sense, but I had hoped for things to be more explicit. To me, springing a bockchain on a system design is kind of a big deal.
• "Contributors have an incentive to use a peer-to-peer system because it can potentially provide more affordable replication services than cloud-based alternatives (see Section 4), therefore they can obtain updates from their favorite content providers for less than on other alternatives." This immediately makes me question the underlying assumption that centralized pricing is driven by infrastructure cost and not by profit maximization. Looking forward to section 4 now, but I'm also bit annoyed you are confronting me with this assumption without any justification.
• regarding absence of free redistribution: I expected something stronger there; given how you talked about incentives for not doing this in the abstract, I gave you some trust in advance and expected some moderately game-theoretic validation later on (not that I would have enjoyed it, but I did expect it). Your leading argument in the section (building non-conformant clients takes technical skill) I found too weak, all you need is a single tenured hippie for everything to break. And this reads like your closing your eyes from reality, where free sharing of copyrighted content runs rampant. I expect the section to draw most of the reviewers criticism, it might be a good decision to present your strongest arguments only. Also you should not base your analysis on the assumption that staying within the system the design is the only option for developers of deviant clients to be compensated. Reality shows that a significant portion of people happily uses adware to access copyrighted content for free, for example. Or a deviant developer (collective) might reach critical wikipedia mass and be sustainable off donations. You might argue that puts them in a shitty situation, but unfortunately their opinion is more important than yours in this case.
• "However, we assume they have limited resources to do so and will be eventually be exposed and blocked," by whom and why?
• "We assume loyal users do not share private keys, therefore signatures uniquely identify them. We do not assume anything about non-loyal users." So a single tenured hippie can pay for updates and then freely share the secret key with anyone to completely circumvent your system?
• "will be used to forever prevent the offending users from ever participating in replication with loyal users again." There seems to be an underlying assumption that creating new keypairs is not cheap, which you should make explicit and justify in order for this argument to hold any weight (if this reasoning is given in your citations, say so).
• "If users break the sequentiality of their updates, they are eventually automatically blacklisted." does user == producer here, and breaking sequentially == forking?
• "Updates are encoded as Git commits [5] and signed by the producer under a self-certifying branch reference [10]." This is a completely jarring switch from high-level design principles discussion to a very specific implementation detail.
• "secret handshake protocol [20][,] otherwise" more comma. Also might want to consider citing the general concept of authenticating handshakes rather than two arbitrarily selected instances. Contrasting ssh with this weird homebrewn solution would make me hesitate for a moment as a review
• "a replica needs devId, the identifier of the account from which developers of the system are retributed." What is the relation between users and devIds? one-to-one?
• section 4: does not resolve to which degree cloud providers charge based on these costs and to which degree they charge because they can make a bigger profit. If 95% of the cloud provider cost was due to a profit margin, then there is no reason to assume that your approach would be significantly less expensive for consumers, because the producers could still aim for the same profit margins.
• related work: I was missing discussion of in-app incentives that are tied to a blockchain, aren't there a bunch of startups that will fix the world this way? Also, nfts? Basically, a lot of web3 enthusiast stuff must be out there. How about work like anylog https://www.cidrdb.org/cidr2020/papers/p9-abadi-cidr20.pdf ?

When I started reading this, I was wondering when the concept of capabilities would pop up, especially given that you talk about "access control" in the abstract (though not thereafter). But by the end, I didn't terribly miss them either.

Congrats =)