John__

+1 on skeleton screens for content on a screen the user has navigated to that isn't loaded yet (like this usecase).

@hesterbruikman I'm not sure if we want to use skeleton loading states when *data is present* and new data is being fetched. Skeleton screens are normally used when there isn't...

@hesterbruikman in the case of the screenshot posted above, a skeleton loading state would be a good idea as in this case data isn't present.

> In an ad-hoc group chat, there is no such thing as 'all users', a user is either an 'admin of the ad-hoc group chat' or 'not an admin of...

@alexandraB99 first of all there should be only a single scrollable area in the screen body area, not sperate scrollable areas for 'Identity verified contacts' and 'contacts'. This should be...

@staheri14 thanks for your reply! I've got some questions to help me better understand exactly what is possible if we use waku store nodes to solve this problem, and to...

> @John-44 Can you please elaborate on the second requirement i.e., scalability. Especially about this part : > > > The history of a community can over time grow large,...

As promised, here is a link to some[ work in progress designs](https://www.figma.com/file/vyw2Y5K74EAj33APmcI0wL/%F0%9F%94%AE-Node%E2%8E%9CDesktop?node-id=572%3A4515 ) for the community history service management screens. A few things to note: - We will probably get...

> In general, it is worth pointing out that e.g. Bittorrent is meant for static content, and a chat history is usually dynamic. To have a canonical immutable representation requires...

> Key however is that every feature has a cost - being decentralised means amplifying that cost, usually - the first step must thus be to precisely define what the...