FORKING GOSSIP to change the UI:
Gossip is MIT licensed and so you can do anything you want with it, including forking it.
I don't mind. I don't consider it a slight against me, and I won't push back. In fact, I recommend forking gossip if you want to change the UI, and I will even help you by supporting new backend functions that you need to get your UI to work (presuming you will be merging in upstream changes outside of the UI).
I've had lots of requests to change gossip substantially. Every single one of them has been with regards to it's UI. Nobody suggests changing the storage engine, or creating async functions that wait on relay responses. Everybody seems to care only about the UI. Well guess what? I consider the UI a necessary evil, a thing that must be coded, but not something I have any real interest in, and generally a distraction from the much more interesting work. That is why I partnered with several other developers who are more keen on UI development.
The problem I have with all the requests to change gossip's UI is that they all go in different directions. They can't all happen. Everybody has a different vision for how they want the gossip UI to work. Which is why I think forks are a good idea. Everybody can get what they want, if they put in the effort.
So here is the thing: gossip's UI is cleanly divided from the rest of the code. The UI reads from global structures and sends messages to the overlord (but you could call overlord functions directly if your UI isn't immediate-mode and is async). It is currently designed for worst case: single thread, not async, immediate mode rendering. But that means it could easily handle all the other cases. You could rip it out and put in an entirely different UI... tauri, gtk4 ... you could probably even get it running under WASM and make the browser the UI.
Most people with grand UI designs don't also write rust code, so I'm not sure if anybody is going to take me up on this. But if anybody was thinking about it and hesitating because they didn't want to make waves, maybe this post will smooth that over.
M. Dilger /
npub1ac…9p35c
2023-10-03 18:59:35
Author Public Key
npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35cPublished at
2023-10-03 18:59:35Event JSON
{
"id": "a562ad1abd95456023ab70d931f7e2ec7f5ed4933daf8331bb093afc4fb6f28a",
"pubkey": "ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49",
"created_at": 1696359575,
"kind": 1,
"tags": [
[
"client",
"gossip"
]
],
"content": "FORKING GOSSIP to change the UI:\n\nGossip is MIT licensed and so you can do anything you want with it, including forking it.\n\nI don't mind. I don't consider it a slight against me, and I won't push back. In fact, I recommend forking gossip if you want to change the UI, and I will even help you by supporting new backend functions that you need to get your UI to work (presuming you will be merging in upstream changes outside of the UI).\n\nI've had lots of requests to change gossip substantially. Every single one of them has been with regards to it's UI. Nobody suggests changing the storage engine, or creating async functions that wait on relay responses. Everybody seems to care only about the UI. Well guess what? I consider the UI a necessary evil, a thing that must be coded, but not something I have any real interest in, and generally a distraction from the much more interesting work. That is why I partnered with several other developers who are more keen on UI development.\n\nThe problem I have with all the requests to change gossip's UI is that they all go in different directions. They can't all happen. Everybody has a different vision for how they want the gossip UI to work. Which is why I think forks are a good idea. Everybody can get what they want, if they put in the effort.\n\nSo here is the thing: gossip's UI is cleanly divided from the rest of the code. The UI reads from global structures and sends messages to the overlord (but you could call overlord functions directly if your UI isn't immediate-mode and is async). It is currently designed for worst case: single thread, not async, immediate mode rendering. But that means it could easily handle all the other cases. You could rip it out and put in an entirely different UI... tauri, gtk4 ... you could probably even get it running under WASM and make the browser the UI.\n\nMost people with grand UI designs don't also write rust code, so I'm not sure if anybody is going to take me up on this. But if anybody was thinking about it and hesitating because they didn't want to make waves, maybe this post will smooth that over.",
"sig": "5d5c8a3c69c078dc11482f09eb495ca2ebead3866dc5a7a96199133bd63ca35ff37d9caf25027aca041c3e3ac64fbc706c27290bfcc4375a19b02c7687a051db"
}