On Sat, Mar 20, 2021 at 12:38:56PM +0100, Lukas Schmidt wrote:
> >>> Sure, you could argue that most centralized services probably just
> >>> visualize an option of deletion or modification while keeping the
> >>> old
> >>> state stored anyway. But I would like to actually provide this
> >>> functi
On 09.03.21 17:22, TheJackiMonster wrote:
> On Tue, 2021-03-09 at 12:28 +0100, carlo von lynX wrote:
>> On Sun, Mar 07, 2021 at 12:23:31PM +0100, TheJackiMonster wrote:
>>> Waiting for the completion of a message is far worse for most users
>>> than looking at dynamic previews or states from my exp
On 3/10/21, TheJackiMonster wrote:
> Hi Karl,
>
> so basically a feature like exporting a stream of messages into a file,
> transporting the file via any external media and importing the messages
> from the file to a peer would help, right?
>
> I think that's possible to integrate because messages
Hi Karl,
so basically a feature like exporting a stream of messages into a file,
transporting the file via any external media and importing the messages
from the file to a peer would help, right?
I think that's possible to integrate because messages get verified with
the senders identity key pair
Hi Jacki,
I just got the last pieces done to complete the core functionality of
> the messenger service I'm working on for a while. So it is updated on
> the main branch now and can be build by enabling the experimental flag.
> (I think it's best letting it experimental until a next major release.
On Tue, 2021-03-09 at 12:28 +0100, carlo von lynX wrote:
> On Sun, Mar 07, 2021 at 12:23:31PM +0100, TheJackiMonster wrote:
> > Waiting for the completion of a message is far worse for most users
> > than looking at dynamic previews or states from my experience.
> > Because
> > you can't expect the
On Sun, Mar 07, 2021 at 12:23:31PM +0100, TheJackiMonster wrote:
> Waiting for the completion of a message is far worse for most users
> than looking at dynamic previews or states from my experience. Because
> you can't expect the people to be physically separated while
> sending/receiving a messag
On Sun, 2021-03-07 at 09:24 +0100, carlo von lynX wrote:
> Good morning!
>
> > > Super inefficient for small pieces of data I would assume,
> > > and introducing so much latency that in the end it feels
> > > slower than using the web. When simple things arrive in-band
> > > you can display them i
Good morning!
> > Super inefficient for small pieces of data I would assume,
> > and introducing so much latency that in the end it feels
> > slower than using the web. When simple things arrive in-band
> > you can display them immediately. I'd rather use FS for
> > things >1M.
On Sat, Mar 06, 20
On Sat, 2021-03-06 at 21:15 +0100, carlo von lynX wrote:
> On Sat, Mar 06, 2021 at 06:55:21PM +0100, TheJackiMonster wrote:
> > Files will most likely be shared through the FS submodule of
> > GNUnet.
> > They get encrypted and the key for decryption gets shared through
> > the
> > messenger servic
On Sat, Mar 06, 2021 at 06:55:21PM +0100, TheJackiMonster wrote:
> Files will most likely be shared through the FS submodule of GNUnet.
> They get encrypted and the key for decryption gets shared through the
> messenger service. That's quite similar to the implementation of
> Threema except this is
On Sat, 2021-03-06 at 17:42 +0100, carlo von lynX wrote:
> On Sat, Mar 06, 2021 at 04:09:17PM +0100, TheJackiMonster wrote:
> > I'm not currently sure if we should use JSON (which is more common
> > in
> > current web) or use PSYC (which would be more efficient). The
> > service
> > itself should a
On Sat, Mar 06, 2021 at 04:09:17PM +0100, TheJackiMonster wrote:
> I'm not currently sure if we should use JSON (which is more common in
> current web) or use PSYC (which would be more efficient). The service
> itself should allow both, so this would probably be something to decide
> on application
Sounds good, I hope the documentation won't take too long.
I've also noticed one bug already which needs to be fixed. So if you
should go straight to testing, I would probably not use
GNUNET_MESSENGER_update(handle) too much currently. ^^'
There's currently a problem in the completion of a member
These features are definitely planned. The second one could require
some changes in the service but I will look into it.
BR
Jacki
On Sat, 2021-03-06 at 11:47 +0100, Schanzenbach, Martin wrote:
> What would also be nice to see:
>
> - GNS records for room discovery
> - reclaimID for user profile m
I've tested communication in a testbed with multiple peers but with two
devices in local network as well.
It's mostly still a struggle exchanging hello-strings and peer-
identities first to get a connection done but this should improve with
development on TNG and the client-side library which shou
I think so too. Documentation is most important currently. Otherwise
it's not easily usable and I wouldn't mind others being able to review
or fix/improve the code.
BR
Jacki
On Sat, 2021-03-06 at 09:01 +0100, Schanzenbach, Martin wrote:
> Cool. Keep us updated.
>
> I know it is a chore, but it w
I took the gnunet-secushare repository which currently does not build.
So I wrote a patch. Next I'll test both secushare and the messenger.
On Sat, 6 Mar 2021 11:47:33 +0100
"Schanzenbach, Martin" wrote:
> What would also be nice to see:
>
> - GNS records for room discovery
> - reclaimID for us
What would also be nice to see:
- GNS records for room discovery
- reclaimID for user profile management / retrieval
Both are probably "client"-side features. As in: implemented by the UI.
BR
Martin
> On 6. Mar 2021, at 02:22, TheJackiMonster wrote:
>
> Hi everyone,
>
> I just got the last p
That sounds pretty awesome!!! Does it also work in the wild
or only within testbed simulations? Does it have any sorts
of server component or does it manage to distribute state
in the gnunet?
The feature list sounds a lot like things that were supposed
to go into secushare but we didn't get there
Cool. Keep us updated.
I know it is a chore, but it would also be great to have documentation:
- As we discussed a small "howto" manual (can wait until CLI is "done" I guess)
- Manpage (see doc/man)
- Handbook entry (see doc/handbook)
BR
Martin
> On 6. Mar 2021, at 02:22, TheJackiMonster wrote
Hi everyone,
I just got the last pieces done to complete the core functionality of
the messenger service I'm working on for a while. So it is updated on
the main branch now and can be build by enabling the experimental flag.
(I think it's best letting it experimental until a next major release.)
22 matches
Mail list logo
