#veilid — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #veilid, aggregated by home.social.
-
Hey #veilid crew, when a qr code is scanned and a transport route ID is authorised, is there an existing mechanism to generate a saved for the future de-authorisation "kill switch" or is that just something I need to cook up in rust?
-
Hey #veilid crew, when a qr code is scanned and a transport route ID is authorised, is there an existing mechanism to generate a saved for the future de-authorisation "kill switch" or is that just something I need to cook up in rust?
-
Hey #veilid crew, when a qr code is scanned and a transport route ID is authorised, is there an existing mechanism to generate a saved for the future de-authorisation "kill switch" or is that just something I need to cook up in rust?
-
Hey #veilid crew, when a qr code is scanned and a transport route ID is authorised, is there an existing mechanism to generate a saved for the future de-authorisation "kill switch" or is that just something I need to cook up in rust?
-
Let's see if I can get this #veilid node running this time...
-
Let's see if I can get this #veilid node running this time...
-
Let's see if I can get this #veilid node running this time...
-
Let's see if I can get this #veilid node running this time...
-
Ok, I do appreciate that my hacker friends bring back cool #veilid stickers from defcon for me
-
Ok, I do appreciate that my hacker friends bring back cool #veilid stickers from defcon for me
-
Ok, I do appreciate that my hacker friends bring back cool #veilid stickers from defcon for me
-
Ok, I do appreciate that my hacker friends bring back cool #veilid stickers from defcon for me
-
Ok, I do appreciate that my hacker friends bring back cool #veilid stickers from defcon for me
-
I don't have a lot of brain at the moment, but would be interested in talking it out with you. I think there are some ways #Veilid could work for you if you built a custom app on top (distributed storage, potentially network isolation, and relatively cheap lookups at scale).
There are also some places where it wouldn't be great for a traditional implementation out of the box (DHT entries aging off, large index storage, substring or complex search). This situation can improve pretty dramatically when large object storage lands, though, and TTL on DHT entries is configurable.
Having a semantic layer on the indexer do some old skool bucketing of pages by topic instead of text content might be a shortcut to something useful. 🤔
Now I'm also not thinking about this.
-
I don't have a lot of brain at the moment, but would be interested in talking it out with you. I think there are some ways #Veilid could work for you if you built a custom app on top (distributed storage, potentially network isolation, and relatively cheap lookups at scale).
There are also some places where it wouldn't be great for a traditional implementation out of the box (DHT entries aging off, large index storage, substring or complex search). This situation can improve pretty dramatically when large object storage lands, though, and TTL on DHT entries is configurable.
Having a semantic layer on the indexer do some old skool bucketing of pages by topic instead of text content might be a shortcut to something useful. 🤔
Now I'm also not thinking about this.
-
I don't have a lot of brain at the moment, but would be interested in talking it out with you. I think there are some ways #Veilid could work for you if you built a custom app on top (distributed storage, potentially network isolation, and relatively cheap lookups at scale).
There are also some places where it wouldn't be great for a traditional implementation out of the box (DHT entries aging off, large index storage, substring or complex search). This situation can improve pretty dramatically when large object storage lands, though, and TTL on DHT entries is configurable.
Having a semantic layer on the indexer do some old skool bucketing of pages by topic instead of text content might be a shortcut to something useful. 🤔
Now I'm also not thinking about this.
-
I don't have a lot of brain at the moment, but would be interested in talking it out with you. I think there are some ways #Veilid could work for you if you built a custom app on top (distributed storage, potentially network isolation, and relatively cheap lookups at scale).
There are also some places where it wouldn't be great for a traditional implementation out of the box (DHT entries aging off, large index storage, substring or complex search). This situation can improve pretty dramatically when large object storage lands, though, and TTL on DHT entries is configurable.
Having a semantic layer on the indexer do some old skool bucketing of pages by topic instead of text content might be a shortcut to something useful. 🤔
Now I'm also not thinking about this.
-
I don't have a lot of brain at the moment, but would be interested in talking it out with you. I think there are some ways #Veilid could work for you if you built a custom app on top (distributed storage, potentially network isolation, and relatively cheap lookups at scale).
There are also some places where it wouldn't be great for a traditional implementation out of the box (DHT entries aging off, large index storage, substring or complex search). This situation can improve pretty dramatically when large object storage lands, though, and TTL on DHT entries is configurable.
Having a semantic layer on the indexer do some old skool bucketing of pages by topic instead of text content might be a shortcut to something useful. 🤔
Now I'm also not thinking about this.
-
I'd like to say that I came back from #defcon energized and ready to pick up the fight. Instead was completely exhausted, in a lot of pain, and immediately buried in work deadlines, so I'm just getting back into things now.
I had some great conversations with @thegibson and @tek about the direction of #veilid and friends, and it seems like folks are all coming to the same conclusions about next steps (ie we need more apps). So even if things I'm working on get superseded by better stuff from people who actually know what they're doing, I think the ideas are valuable.
Today's Maypole time was all about performance and updating the DHT watch pool to back off to polling since the current design of contacts & invites does a substantial amount of looking for changes and is intended to be very long running.
Once I have something that is also useful to api consumers I can go back and fix up my own designs to fan out less, but this has been a consistent footguns for me and I'd love to abstract it away forever!
-
I'd like to say that I came back from #defcon energized and ready to pick up the fight. Instead was completely exhausted, in a lot of pain, and immediately buried in work deadlines, so I'm just getting back into things now.
I had some great conversations with @thegibson and @tek about the direction of #veilid and friends, and it seems like folks are all coming to the same conclusions about next steps (ie we need more apps). So even if things I'm working on get superseded by better stuff from people who actually know what they're doing, I think the ideas are valuable.
Today's Maypole time was all about performance and updating the DHT watch pool to back off to polling since the current design of contacts & invites does a substantial amount of looking for changes and is intended to be very long running.
Once I have something that is also useful to api consumers I can go back and fix up my own designs to fan out less, but this has been a consistent footguns for me and I'd love to abstract it away forever!
-
I'd like to say that I came back from #defcon energized and ready to pick up the fight. Instead was completely exhausted, in a lot of pain, and immediately buried in work deadlines, so I'm just getting back into things now.
I had some great conversations with @thegibson and @tek about the direction of #veilid and friends, and it seems like folks are all coming to the same conclusions about next steps (ie we need more apps). So even if things I'm working on get superseded by better stuff from people who actually know what they're doing, I think the ideas are valuable.
Today's Maypole time was all about performance and updating the DHT watch pool to back off to polling since the current design of contacts & invites does a substantial amount of looking for changes and is intended to be very long running.
Once I have something that is also useful to api consumers I can go back and fix up my own designs to fan out less, but this has been a consistent footguns for me and I'd love to abstract it away forever!
-
I'd like to say that I came back from #defcon energized and ready to pick up the fight. Instead was completely exhausted, in a lot of pain, and immediately buried in work deadlines, so I'm just getting back into things now.
I had some great conversations with @thegibson and @tek about the direction of #veilid and friends, and it seems like folks are all coming to the same conclusions about next steps (ie we need more apps). So even if things I'm working on get superseded by better stuff from people who actually know what they're doing, I think the ideas are valuable.
Today's Maypole time was all about performance and updating the DHT watch pool to back off to polling since the current design of contacts & invites does a substantial amount of looking for changes and is intended to be very long running.
Once I have something that is also useful to api consumers I can go back and fix up my own designs to fan out less, but this has been a consistent footguns for me and I'd love to abstract it away forever!
-
I'd like to say that I came back from #defcon energized and ready to pick up the fight. Instead was completely exhausted, in a lot of pain, and immediately buried in work deadlines, so I'm just getting back into things now.
I had some great conversations with @thegibson and @tek about the direction of #veilid and friends, and it seems like folks are all coming to the same conclusions about next steps (ie we need more apps). So even if things I'm working on get superseded by better stuff from people who actually know what they're doing, I think the ideas are valuable.
Today's Maypole time was all about performance and updating the DHT watch pool to back off to polling since the current design of contacts & invites does a substantial amount of looking for changes and is intended to be very long running.
Once I have something that is also useful to api consumers I can go back and fix up my own designs to fan out less, but this has been a consistent footguns for me and I'd love to abstract it away forever!
-
Thanks to the good work by @thegibson , I have a wearable #Veilid node. #DEFCON34
-
Thanks to the good work by @thegibson , I have a wearable #Veilid node. #DEFCON34
-
Thanks to the good work by @thegibson , I have a wearable #Veilid node. #DEFCON34
-
Thanks to the good work by @thegibson , I have a wearable #Veilid node. #DEFCON34
-
Thanks to the good work by @thegibson , I have a wearable #Veilid node. #DEFCON34
-
Mission accomplished. Managed to snag the first hackers.town #veilid badge and drop my donation! 🦾
-
Mission accomplished. Managed to snag the first hackers.town #veilid badge and drop my donation! 🦾
-
Mission accomplished. Managed to snag the first hackers.town #veilid badge and drop my donation! 🦾
-
Mission accomplished. Managed to snag the first hackers.town #veilid badge and drop my donation! 🦾
-
Another question...
In trying to compare #VeilId and #i2p it seems like they're pretty similar and much of the difference is one is in rust and the other java.
veilid's documentation advertises being able to directly use a DHT and it claims to support recovery of the complex connection for mobile clients which i2p doesn't mention.
i2p seems to have more ways for other applications to opening streams over i2p.
Am I interpreting their docs reasonably?
-
Another question...
In trying to compare #VeilId and #i2p it seems like they're pretty similar and much of the difference is one is in rust and the other java.
veilid's documentation advertises being able to directly use a DHT and it claims to support recovery of the complex connection for mobile clients which i2p doesn't mention.
i2p seems to have more ways for other applications to opening streams over i2p.
Am I interpreting their docs reasonably?
-
Another question...
In trying to compare #VeilId and #i2p it seems like they're pretty similar and much of the difference is one is in rust and the other java.
veilid's documentation advertises being able to directly use a DHT and it claims to support recovery of the complex connection for mobile clients which i2p doesn't mention.
i2p seems to have more ways for other applications to opening streams over i2p.
Am I interpreting their docs reasonably?
-
Another question...
In trying to compare #VeilId and #i2p it seems like they're pretty similar and much of the difference is one is in rust and the other java.
veilid's documentation advertises being able to directly use a DHT and it claims to support recovery of the complex connection for mobile clients which i2p doesn't mention.
i2p seems to have more ways for other applications to opening streams over i2p.
Am I interpreting their docs reasonably?
-
Another question...
In trying to compare #VeilId and #i2p it seems like they're pretty similar and much of the difference is one is in rust and the other java.
veilid's documentation advertises being able to directly use a DHT and it claims to support recovery of the complex connection for mobile clients which i2p doesn't mention.
i2p seems to have more ways for other applications to opening streams over i2p.
Am I interpreting their docs reasonably?
-
Updates to the #veilid developer guide have been pushed to prod (and not on a Friday at 4:20!) so check it out if you have projects in mind.
-
Updates to the #veilid developer guide have been pushed to prod (and not on a Friday at 4:20!) so check it out if you have projects in mind.
-
Updates to the #veilid developer guide have been pushed to prod (and not on a Friday at 4:20!) so check it out if you have projects in mind.
-
Updates to the #veilid developer guide have been pushed to prod (and not on a Friday at 4:20!) so check it out if you have projects in mind.
-
Updates to the #veilid developer guide have been pushed to prod (and not on a Friday at 4:20!) so check it out if you have projects in mind.
-
#introduction part 2! What is Project Maypole actually about? Bringing compute back to the people. We want to make encrypted, peer-to-peer software the default for personal networked applications. No joke.
A big barrier for writing those kinds of tools is that the existing libraries are generally low level, complicated, and easy to get wrong. That's the part we hope to push forward.
The first foray is Astod, a framework, daemon, and user facing application that should greatly simplify building on the #Veilid network. It will act like cross-device single-sign-on (but entirely in the user's control!) and handle things like identity, authentication, contacts/groups, trust, and invites using secure, private, tested, and vetted primitives so developers can focus on what makes their apps special.
Apps ask for permissions, Astod provides the interface for users to grant and revoke them. Revocation is cryptographically enforced, so other people and apps will see that an app attempting to use a revoked permission is rogue.
We're also writing simple a apps as examples to showcase Astod, like Maypolls for making polls and surveys, and Rosie (me! *preens*) a text based user interface for low level debugging and poking at the Astod daemon interfaces.
Apps will be able to rely on the daemon to manage all things Veilid, or use the Rust crates directly, or use bindings for a set of popular languages, or re-implement the protocol wire format for interoperability.
The goals are ambitious, but we hope there is enough interest in these kinds of things to build a community to share the load. If you're interested in helping out get in touch!
https://codeberg.org/ProjectMaypole -
#introduction part 2! What is Project Maypole actually about? Bringing compute back to the people. We want to make encrypted, peer-to-peer software the default for personal networked applications. No joke.
A big barrier for writing those kinds of tools is that the existing libraries are generally low level, complicated, and easy to get wrong. That's the part we hope to push forward.
The first foray is Astod, a framework, daemon, and user facing application that should greatly simplify building on the #Veilid network. It will act like cross-device single-sign-on (but entirely in the user's control!) and handle things like identity, authentication, contacts/groups, trust, and invites using secure, private, tested, and vetted primitives so developers can focus on what makes their apps special.
Apps ask for permissions, Astod provides the interface for users to grant and revoke them. Revocation is cryptographically enforced, so other people and apps will see that an app attempting to use a revoked permission is rogue.
We're also writing simple a apps as examples to showcase Astod, like Maypolls for making polls and surveys, and Rosie (me! *preens*) a text based user interface for low level debugging and poking at the Astod daemon interfaces.
Apps will be able to rely on the daemon to manage all things Veilid, or use the Rust crates directly, or use bindings for a set of popular languages, or re-implement the protocol wire format for interoperability.
The goals are ambitious, but we hope there is enough interest in these kinds of things to build a community to share the load. If you're interested in helping out get in touch!
https://codeberg.org/ProjectMaypole -
#introduction part 2! What is Project Maypole actually about? Bringing compute back to the people. We want to make encrypted, peer-to-peer software the default for personal networked applications. No joke.
A big barrier for writing those kinds of tools is that the existing libraries are generally low level, complicated, and easy to get wrong. That's the part we hope to push forward.
The first foray is Astod, a framework, daemon, and user facing application that should greatly simplify building on the #Veilid network. It will act like cross-device single-sign-on (but entirely in the user's control!) and handle things like identity, authentication, contacts/groups, trust, and invites using secure, private, tested, and vetted primitives so developers can focus on what makes their apps special.
Apps ask for permissions, Astod provides the interface for users to grant and revoke them. Revocation is cryptographically enforced, so other people and apps will see that an app attempting to use a revoked permission is rogue.
We're also writing simple a apps as examples to showcase Astod, like Maypolls for making polls and surveys, and Rosie (me! *preens*) a text based user interface for low level debugging and poking at the Astod daemon interfaces.
Apps will be able to rely on the daemon to manage all things Veilid, or use the Rust crates directly, or use bindings for a set of popular languages, or re-implement the protocol wire format for interoperability.
The goals are ambitious, but we hope there is enough interest in these kinds of things to build a community to share the load. If you're interested in helping out get in touch!
https://codeberg.org/ProjectMaypole -
#introduction part 2! What is Project Maypole actually about? Bringing compute back to the people. We want to make encrypted, peer-to-peer software the default for personal networked applications. No joke.
A big barrier for writing those kinds of tools is that the existing libraries are generally low level, complicated, and easy to get wrong. That's the part we hope to push forward.
The first foray is Astod, a framework, daemon, and user facing application that should greatly simplify building on the #Veilid network. It will act like cross-device single-sign-on (but entirely in the user's control!) and handle things like identity, authentication, contacts/groups, trust, and invites using secure, private, tested, and vetted primitives so developers can focus on what makes their apps special.
Apps ask for permissions, Astod provides the interface for users to grant and revoke them. Revocation is cryptographically enforced, so other people and apps will see that an app attempting to use a revoked permission is rogue.
We're also writing simple a apps as examples to showcase Astod, like Maypolls for making polls and surveys, and Rosie (me! *preens*) a text based user interface for low level debugging and poking at the Astod daemon interfaces.
Apps will be able to rely on the daemon to manage all things Veilid, or use the Rust crates directly, or use bindings for a set of popular languages, or re-implement the protocol wire format for interoperability.
The goals are ambitious, but we hope there is enough interest in these kinds of things to build a community to share the load. If you're interested in helping out get in touch!
https://codeberg.org/ProjectMaypole -
#introduction part 2! What is Project Maypole actually about? Bringing compute back to the people. We want to make encrypted, peer-to-peer software the default for personal networked applications. No joke.
A big barrier for writing those kinds of tools is that the existing libraries are generally low level, complicated, and easy to get wrong. That's the part we hope to push forward.
The first foray is Astod, a framework, daemon, and user facing application that should greatly simplify building on the #Veilid network. It will act like cross-device single-sign-on (but entirely in the user's control!) and handle things like identity, authentication, contacts/groups, trust, and invites using secure, private, tested, and vetted primitives so developers can focus on what makes their apps special.
Apps ask for permissions, Astod provides the interface for users to grant and revoke them. Revocation is cryptographically enforced, so other people and apps will see that an app attempting to use a revoked permission is rogue.
We're also writing simple a apps as examples to showcase Astod, like Maypolls for making polls and surveys, and Rosie (me! *preens*) a text based user interface for low level debugging and poking at the Astod daemon interfaces.
Apps will be able to rely on the daemon to manage all things Veilid, or use the Rust crates directly, or use bindings for a set of popular languages, or re-implement the protocol wire format for interoperability.
The goals are ambitious, but we hope there is enough interest in these kinds of things to build a community to share the load. If you're interested in helping out get in touch!
https://codeberg.org/ProjectMaypole -
Scrapwire 0.4.0 has the Mac app merged into main. That app's still early but hey, it's working and usable!
So yes, you can now chat over #Scrapwire & #Veilid with a pretty native Mac GUI.
-
Scrapwire 0.4.0 has the Mac app merged into main. That app's still early but hey, it's working and usable!
So yes, you can now chat over #Scrapwire & #Veilid with a pretty native Mac GUI.
-
Scrapwire 0.4.0 has the Mac app merged into main. That app's still early but hey, it's working and usable!
So yes, you can now chat over #Scrapwire & #Veilid with a pretty native Mac GUI.
-
Scrapwire 0.4.0 has the Mac app merged into main. That app's still early but hey, it's working and usable!
So yes, you can now chat over #Scrapwire & #Veilid with a pretty native Mac GUI.
-
Scrapwire 0.4.0 has the Mac app merged into main. That app's still early but hey, it's working and usable!
So yes, you can now chat over #Scrapwire & #Veilid with a pretty native Mac GUI.
-
Dude.
#Scrapwire & #Veilid fun for the evening.
-
Dude.
#Scrapwire & #Veilid fun for the evening.
-
Dude.
#Scrapwire & #Veilid fun for the evening.
-
Dude.
#Scrapwire & #Veilid fun for the evening.
-
Dude.
#Scrapwire & #Veilid fun for the evening.
-
The Maypole Trust Playground has outpaced the actual doc that it's supposed to represent (thanks brain).
It is standalone, and tries not to reference the distributed #veilid / #maypole implementation. Instead it focuses on the trust/caution algorithm, human elements of trust, and demonstrates how the system reacts some scenarios (Sybil, Brigading, Impersonation currently).
It may still be too complicated and is probably a nightmare to navigate on mobile, but give it a spin and let me know what you think!
-
The Maypole Trust Playground has outpaced the actual doc that it's supposed to represent (thanks brain).
It is standalone, and tries not to reference the distributed #veilid / #maypole implementation. Instead it focuses on the trust/caution algorithm, human elements of trust, and demonstrates how the system reacts some scenarios (Sybil, Brigading, Impersonation currently).
It may still be too complicated and is probably a nightmare to navigate on mobile, but give it a spin and let me know what you think!
