Welcome to the little GNUnet world!
I've seen fine and appetizing commits regarding gnunet-guile.
Thank you!
In former times, Amirouche Boubekki wrote:
> There is also a real-time or near realtime aspect that I would
> like to tackle. I could come up with the naming scheme that will
> allow to pull for new links. But it will be nice to be notified
> of new links (after subscription). I think about gnunet-social
> and gnunet-psyc services.
The idea of psyc pubsub is that you should also be able to deliver
the files themselves and they would trigger notification on arrival,
no extra bureaucracy to actually fetch them. But that's theory.
Given the current implementation situation, if the gnunet-social
API/CLI is used, it would inefficiently send a copy of the file to
each recipient without multicast, which is worse than a file
caching strategy that gnunet-fs or any database would offer.
But of course we can use psyc-pubsub just for the notifications,
then fetch the files from gnunet-fs.
> Maybe my question is better phrased as:
>
> Q: How can I help secushare?
Thanks for asking. When implementing a psyc-pubsub tool
you may bump into bugs we are still in process of fixing.
Currently our pubsubs work somewhat non-deterministically...
The plans you discussed using GNS have the disadvantage
that you not only have to poll GNS for updates, you also
have to periodically push the updates into GNS. So you
have an overhead/latency trade-off to choose from.
The idea of running git or other distributed database
over CADET can have very interesting use cases, but it
doesn't provide a push mechanism. In fact it can
make a lot of sense to use git over PSYC in order to
achieve realtimeness, should PSYC's own distributed
database not be advanced enough. Think of it like
pushing git updates by e-mail and disabling 'git pull'.
So to me it makes sense to try 'gnunet-social' (what a
misnomer, we have to change it into 'psyc-pubsub'),
to create the subscription channel, then send the URIs
that gnunet-publish produces out in real-time and watch
how gnunet-fs gasps for air delivering the content.
On Sat, Jan 13, 2018 at 03:25:10PM +0100, Christian Grothoff wrote:
> One idea I had was to basically run Git over GNUnet. Whenever you clone
> a repository, you remember where you cloned from, and offer updates
> ('push') to the source. So we'd build a parallel notification graph for
> Git commits. Basically, run Git over CADET and in hooks additionally
> track where you cloned from to push back changes.
Actually that is what git does by default, to push back
to the origin. What it would take to re-invent a pubsub
mechanism in this case is that each node runs a git node
and allows the origin to *push* into the subscriber repos.
Once you have that you need a signaling protocol that tells
the origin what you would like to subscribe. In other words
it's probably not less work than fixing psyc-pubsub.
> A prototype was built by students (basically a special command that
> would wrap around "git" and setup all the required hooks), but was never
> completed. If you care, I can try to find it.
Did they do what I described or did I not understand what
you wrote? In any case sounds like an interesting work of
glue to look into. I never really considered that we could
be doing a dirty hack pubsub using git over CADET. In fact
if you use a patch-receiving protocol rather than 'git push',
then it would even be compatible with gnunet-multicast.
Still, the signaling equals rewriting psyc-pubsub, right?
Cheers!
--
E-mail is public! Talk to me in private using encryption:
http://loupsycedyglgamf.onion/LynX/
irc://loupsycedyglgamf.onion:67/lynX
https://psyced.org:34443/LynX/
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers
