This is Cool!

[amark]

you already got some fans in the GUN chat room! Come talk to them, show off, and shill TopGUN! :)

[ivkan]

Exciting news! I know you have an amazing community, thanks @amark for reaching out!

[pwFoo]

Great work! Would love to see a better structured and commented gun code base for a more stable Gun future!

[ivkan]

Thanks for your feedback @pwFoo !
I plan to start working on the documentation soon, but I don't know when it will be available. Some TopGun methods will be different from those in Gun.

[amark]

@ivkan come talk about this in the chat room! Spread the word!!

[mrbluecoat]

+1

Reminds me of the abandoned https://github.com/chain-gun/chaingun

[pwFoo]

Is there a roadmap / todos to see progress of TopGun?

[ivkan]

Thank you for your interest in developing TopGun. Last year, I attempted to create a system similar to Gun, but I encountered limitations that prevent future development. The main objectives I aim to address now are:

1. Using SQLite to store data in the browser and possibly PostgreSQL on the server, enabling queries with searching and sorting capabilities.
2. Utilizing Borsh for data serialization instead of JSON.
3. Implementing an efficient method to subscribe to real-time data changes in the database.
4. Employing group- and role-based data access.

Currently, we do not have an estimated release date for the new version. Thank you for your interest!

[digitalextremist]

This was pointed out to me in the course of looking at rebooting chaingun as gun.ts here: chain-gun/chaingun#76

This seems more recently active than that though. Not sure how both differ yet, or where they are relative to GUN itself.

As mentioned in chat I am looking at this from the big picture backward before picking where to start the climb that has been attempted several times over the years it seems: https://matrix.to/#/!apmkrFyPwFRRvQgtEw:gitter.im/$AdKw_zt1no-KkDz3tNMCUVgr7ayMyLSpwMVq6RG4LL0?via=gitter.im&via=matrix.org

Would love to collaborate and align around a shared vision. I aim to bring decentrality out in reference implementations which actually carry the entirety of digital life, not just content or social activity, but all of the essentials. And not just online, but offline first, then online. Seems like GUN has a lot to offer for that.

For starters I have (4) in the list, resolved (1) mostly, and am resolving (3) now but I would cross (2) later in case YAGNI.

In my understanding, all this is still a proof of concept. It does not seem GUN was as much code as an indomitable and fresh spirit, ready to lift big and go long. Not really a step yet, more like proof that walking is possible today. Soon running!

Now we need reference implementations which are not remakes of systems which mainly entertain or pacify attention versus enables/empowers actual free life; essentials need to get handled. Then perhaps at the prototype phase we can bullet-proof the veins, as ZMQ long ago forecast. And which RINA also wanted but then could not carry out in the wild, and since dropped. Not a lot makes it out of the academic phase and into general use. It seems we are overcoming that here. And a lot of what we are doing is still just working around TCP/IP so that ought to be called out and just left for later once the infrastructure is reworked. We are not going to be on this infrastructure forever. For now, here we are.

Seems like going deep into performance tuning on object of choice for transfer sounds to be before a production-ready standard, after several years of beating several internetworked reference implementations to death with real successful lives and beloved engagement. We need to fit the essential needs of individuals and various types of formations, and break out of "necessary evil" in the minds of regular persons and organizational leaders, we can then exit JavaScript under the interface layer, which sounded like the plan all along.

For example my choice of infrastructural language in the 'server' and 'agent' aspects alongside 'client' as we have now, is likely Crystal by mostly preference, and that or Rust or whatever high-performance language can do the heavy lifting later. That would be a waterline when we were about to do embedded systems. That is way more appropriate time to tune the specification on a data object level, and there is a huge amount of depth in systems we lack at this phase to really know what the data object needs to be. Does not need to be one language or, just needs to be one standard and then the language can be swapped out, or have different implementations for diversity and preference's sake. I have invested a lot in the data object as-is, and am looking at dropping better objects into GUN not really changing the data objects. We still lack data that meant an individual or formation thrived and met its targets. We still only have data which is tangential or pre-valuable. I really want to see legitimately essential data happening, then tune.

Please correct me if I am wrong or am missing anything. I am coming into this particular codebase and its relatives fresh, but with the same drives and hopes ( but many new powers built up ) from the same prior eras leading up to then and now. To me this fits in a multi-decade window, in a multi-millennia turning point. A lot of us know we are still only just beginning.

I am way glad, most of all, just to see that so many evidently still really care! 🧡 🏴

[ivkan]

Thank you for your thoughtful message, @digitalextremist. I appreciate your interest in the project and your perspective on the larger context of decentralized technologies.

To clarify where TopGun stands today: I initially started by reimplementing gun in TypeScript with a foundation from chaingun, but the project has evolved significantly. Rather than creating a direct port, I've been developing a hybrid approach that combines the strengths of decentralized graph databases with traditional relational databases.

The current direction involves using PostgreSQL as the backend server database while maintaining offline-first capabilities. I've been working on a document-oriented system with a well-defined schema, which provides more structure and query capabilities than the original free-form approach.

Key components I'm focusing on now:

• Real-time data synchronization with conflict resolution
• Structured document storage with proper access controls
• Team/role-based permissions
• Channel-based collaboration
• Efficient change tracking and synchronization

I agree with your sentiment about practical implementations that serve real needs rather than just conceptual demonstrations. My goal is to create something that balances the decentralized ethos with the practical requirements organizations have for data structure, querying, and security.

The project is still in active development, and I haven't publicly announced the new direction yet. I'm aiming for a release in the coming months.

[digitalextremist]

Much appreciated on the fast response @ivkan; I have been looking for a Marco <-> Polo type echo-back, so thank you.

We have a lot of the same focus. That is great to know. However I can help you I would, if that is better than spreading out further. I would go deeper rather than wider if possible, to help concentrate energies on this. But without losing our own unique direction within decentrality. I have a lot to potentially bring to the table in the areas you mentioned.

I will focus on putting out my reference implementation without any of the GUN pieces first, since I am focusing on the items you mentioned. Then I will work to properly integrate the powers of GUN concepts. In the meantime I appreciate your insight and respect your experience and positioning in this wise-to-grow area. I look very forward to whatever you might announce. Is that going to be something easy to find or will it be announced here also and I will be pinged?

[ivkan]

Thank you for your continued interest, @digitalextremist. I appreciate your offer of help and collaboration on shared goals in the decentralized space.

At this stage, several critical components of the project are still under active development and not yet completed. I'm working to establish a minimal viable implementation that properly demonstrates the new direction I've described.

Once the project reaches a state where it's functional enough for external testing and collaboration, I'll update the main branch of this repository with the new code. I'll also post an update in this issue to notify everyone who's been following along. This way, you'll be pinged directly when there's something tangible to explore.

[amark]

guys, shit implementations in Rust perform sucky, shit implementations with Postgres perform sucky, there's no magic, nothing will save you except battletesting your code against millions of users. Let me help you "compete" with GUN:

https://github.com/gundb/panic-server

write a distributed load & correctness test and it'll simulate scale (tho note: don't trust virtual concurrency, load panic-client from as many physically different devices as possible). And we'll all be winning in no time.

building scalable tech is ~7% the battle. Getting it deployed to REAL users & teams is 90%, then the real doozey is the last 3% when establishments you disrupt come with lawfare, bribery, suppression, drugging your colleagues, and rarely enough to look like an "accident" or "suicide": assassinations.