GNUnet Monthly Meeting Sunday, 7th May, 10 AM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 7th May, 10 AM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 10:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 10:00 this sun' Cheers, Bastian Schmidt
Re: Re: GNUnet Project GSOC 2023 Contributor
> We do have a monthly meeting on the first Sunday of the month 20:00 > (Berlin/Rome) through mumble on gnunet.org. > If you want you can join us next time. > > Best > Martin Sure about the time for future meetings? To my knowledge its still 10 A.M. Greetings, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 5th March, 10 AM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 5th March, 10 AM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 10:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 10:00 this sun' Cheers, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 5th February, 10 AM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 5th February, 10 AM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 10:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 10:00 this sun' Cheers, Bastian Schmidt
gnunet.org currently inaccessable - time-related error - renewing of expired certificate maybe necessary
Hello, visiting gnunet.org via TOR browser gives this output: Button next to URL bar: 'Not Secure' - Connection is not secure 'Your Computer Clock is Wrong Your computer thinks it is 1/28/2023, which prevents Tor Browser from connecting securely. To visit www.gnunet.org, update your computer clock in your system settings to the current date, time, and time zone, and then refresh www.gnunet.org. Learn more…' My system clock is correct. Clicking on Lean more gives leads to this website - https://support.mozilla.org/en-US/kb/troubleshoot-time-errors-secure-websites?as=u_source=inproduct - of which this section fits the best to the reported issue: 'Contact the website owner If you get a time-related error on a secure website and you have already checked the correct settings of your system’s clock, please contact the owner of the website which you can’t access and inform them of the problem. The website owner might need to renew the expired certificate, for example. ' Greetings, Bastian Schmidt
GNUnet December Meeting/GNUnet e.V. General Assembly 2022 (online) Sunday, 4th December, 10 AM Paris/Berlin/Rome
Dear all, quick reminder: Our upcoming December online meeting will be something special—the GNUnet e.V. General Assembly 2022. It will take place on Sunday, 4th December, 10 AM Paris/Berlin/Rome—just as regular monthly meetings would do— on mumble server: gnunet.org everyone is very invited! The statute allows members of GNUnet e.V. to send the board of directors proposals to the agenda up until 2 weeks before the General Assembly—https://git.gnunet.org/gnunet-ev.git/tree/satzung.tex#n185 . So, deadline for that is today, 20th November. Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe The next regular monthly meeting will be next year, only 5th February 2023—there will be no meeting on January. Cheers, Bastian Schmidt P.S.—reminder to the board of directors: According to the statute the call-up to the General Assembly will be sent electronically by the board of directors to all members of GNUnet e.V. 1 week before the General Assembly—https://git.gnunet.org/gnunet-ev.git/tree/satzung.tex#n189
Reminder: Official invitation to GNUnet e.V. GA needs to be sent out today, 20th November
Dear all, quick reminder for sending the official invitation to GNUnet e.V. GA in time: GNUnet e.V. GA takes place on 4th December and needs to be officially announced two weeks before with explanation that Satzung is changed (and what is changed). That is right now, today, 20th November. Cheers, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 6th November, 10 AM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 6th November, 10 AM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 10:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 10:00 this sun' Cheers, Bastian Schmidt
Re: Re: Website 'gnunet.org' producing weird output currently
Confirmation: The issue reported by me is fixed now. --- Ursprüngliche Nachricht --- Von: Martin Schanzenbach Datum: 22.10.2022 12:22:40 An: hyazin...@emailn.de Betreff: Re: Website 'gnunet.org' producing weird output currently > Should be fixed. > > On 21.10.22 14:54, hyazin...@emailn.de wrote: > > Hello, > > > > visiting 'gnunet.org' with TOR browser currently is prompting a warning > because of an invalid certificate. > > Clicking the 'accept and continue' button is leading to the GNUnet paper > bibliography - a plain 'html'-website, instead of the usual > 'gnunet.org'-website. > Excerpt: > > > > "Selected Papers in Meshnetworking > > > > The GNUnet Bibliography | Selected Papers in Meshnetworking > > > > By topic | By date | By author > > Topics: > > > > Architecture CADET Communication Computer Science - Cryptography > and Security DHT DNS DNSSEC Decentralisation Future Internet GNU Name System > GNUnet Identity and Access Management Internet Linux MORECOWBELL NAMECOIN > Name resolution P2P PKI POSIX Panic Privacy preserving R5N ReclaimID > Self-sovereign > identity Social networking TLS Taler Technology and society Unsorted User > Attributes X-vine abuse anomaly anonymity auctions blind signatures byzantine > consensus byzantine fault tolerance censorship consensus cooperative cryogenic > decentralization detection distributed hash table economics encoding > encryption > event-driven flow control home router incentives intrusion detection > measurement > memory erasure messaging multicast network architecture obsolete database > payments peer-to-peer performance performance analysis physical access power > privacy private information retrieval publish-subscribe > > pubsub reputation resilience resource allocation routing secure multi-party > computation secure multiparty computation self-organization set reconciliation > social interaction static analysis testbed voting web > > > > Publications by topic > > Architecture > > > > Zur Idee herrschaftsfreier kooperativer Internetdienste (PDF) > > by Christian Ricardo Kühne. > > In FIfF-Kommunikation, 2016. (BibTeX entry) (Download bibtex record) > > > (direct link) (website)" > > > > > > Greetings, > > Bastian Schmidt > > > > > > >
Website 'gnunet.org' producing weird output currently
Hello, visiting 'gnunet.org' with TOR browser currently is prompting a warning because of an invalid certificate. Clicking the 'accept and continue' button is leading to the GNUnet paper bibliography - a plain 'html'-website, instead of the usual 'gnunet.org'-website. Excerpt: "Selected Papers in Meshnetworking The GNUnet Bibliography | Selected Papers in Meshnetworking By topic | By date | By author Topics: Architecture CADET Communication Computer Science - Cryptography and Security DHT DNS DNSSEC Decentralisation Future Internet GNU Name System GNUnet Identity and Access Management Internet Linux MORECOWBELL NAMECOIN Name resolution P2P PKI POSIX Panic Privacy preserving R5N ReclaimID Self-sovereign identity Social networking TLS Taler Technology and society Unsorted User Attributes X-vine abuse anomaly anonymity auctions blind signatures byzantine consensus byzantine fault tolerance censorship consensus cooperative cryogenic decentralization detection distributed hash table economics encoding encryption event-driven flow control home router incentives intrusion detection measurement memory erasure messaging multicast network architecture obsolete database payments peer-to-peer performance performance analysis physical access power privacy private information retrieval publish-subscribe pubsub reputation resilience resource allocation routing secure multi-party computation secure multiparty computation self-organization set reconciliation social interaction static analysis testbed voting web Publications by topic Architecture Zur Idee herrschaftsfreier kooperativer Internetdienste (PDF) by Christian Ricardo Kühne. In FIfF-Kommunikation, 2016. (BibTeX entry) (Download bibtex record) (direct link) (website)" Greetings, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 2nd October, 8 PM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 2nd October, 8 PM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 20:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 20:00 this sun' Cheers, Bastian Schmidt
Re: The future of the file-sharing service
My 2 cents - general top priorities for file sharing applications:
• Make it as anonymous/secure and distributed as possible - 5-eye-safe
• Make it streaming-capable
Greetings,
Bastian Schmidt
--- Ursprüngliche Nachricht ---
Von: madmurphy
Datum: 19.09.2022 20:42:45
An: gnunet-developers
Betreff: The future of the file-sharing service
> Hi all,
> On Thu, Sep 15, 2022 at 2:55 PM Maxime Devos
> wrote:
>
> Myself, I'm very interested in the file-sharing service and DHT service --
>
> I would like to implement (Guix) substitutes over GNUnet (I already sent
> a
> POC implementation previously, but it wasn't a very nice implementation,
>
> e.g. there was no fallback to regular http / https, that's why I started
>
> scheme-gnunet, to make GNUnet easier to use from Guile.
>
> I know that probably the FS service is not the priority at the moment, but
>
> I was thinking that nothing forbids to imagine now how an ideal FS service
>
> could look like. Time ago I had written down some of the features that I
>
> believe a future FS module will need to implement. I paste my list here,
>
> with the hope of leaving food for thought for a brain storming.
>
> What FS needs to have:
>
>1. Possibility of sharing a file while it is still being downloaded
>(parts of it, of course)
>2. Metadata must be editable and sharable
>3. Search keywords must be visible, editable, sharable (part of the
>metadata?)
>4. Introduction of a rating mechanism for files (against spam)
>5. Allow reverse search (i.e. chk-URI lookup)
>6. Automatically and fully auto-unindex a file when it is missing
>7. Autoshare the dynamic content of a directory and update its index in
>
>real time (e.g. if I “autoshare” the content of
>/srv/filesharing/gnunet/madmurphy/, when I add foobar.txt to that
>directory it must be automatically indexed – the opposite if I remove
> it)
>8. Implement file statistics (download counter? last seen? etc.) – this
>
>should allow the network to get rid easily of “lost” content
>9. Implement a NOT operator for search keywords (a tilde, “~”?)
>10. Implement an OR operator (a vertical bar, “|”? currently not writing
>
>any operator equals OR, but we need an explicit OR operator if we want
> to
>implement the next point)
>11. Allow parenthesis parsing for AND/OR/NOT operators; this will
>require that operators can be followed by spaces (e.g. gnunet-search
>+required '+' '(' optional1 '|' optional2 ')')
>12. The output filename must become optional in gnunet-download. If not
>
>specified, the file/directory must be downloaded using the original
>filename it was published with – if currently this information is not
>
>always saved during publishing, then we must make sure that it is always
>
>saved (this is part of the metadata too and must be editable)
>
> My two cents. Please do not hesitate to post your comments on these
> proposals or add new ideas.
>
> --madmurphy
>
Re: Re: A more general question about curl
Hello everyone, wget2 community is hearing our conversation and is reaching out to us for collaboration: story - short: > On 10. Sep 2022, at 20:53, Tim Rühsen wrote: > > just found this issue: https://gitlab.com/gnuwget/wget2/-/issues/550 > > Feel free to add the details needed for GNUnet. story - medium: > On 10. Sep 2022, at 20:47, Tim Rühsen wrote: > > TL;DR the wget2 project is willing to help and a multi API may be easy > to implement. But someone has to write down the exact needs. Full story, its rest - https://lists.gnu.org/archive/html/wget-dev/2022-09/msg8.html : > On 10. Sep 2022, at 20:53, Tim Rühsen wrote: > I try to explain what libwget does today and that it seems very straight > forward to implement an API - and by the way - everybody is invited to do > that :-) > > Libwget has several layers of abstraction of accessing the network stack(s). > > So you have indeed the synchronously, super simplified > response = wget_http_get(...) like in example/http_get.c > > Then there is async HTTP API layer with more control over the details, see > example/http_get2.c. > > err = wget_http_open(, url); // comes back immediately > err = wget_http_send_request(conn, req); // comes back immediately > > resp = wget_http_get_response(conn); // waits until error/timeout or response > > wget_http_close(); > > While you could send several requests over a single connection, HTTP/1.1 has > issues with it. But it works fine with HTTP/2. In this case > wget_http_get_response(conn) can be called in a loop, returning the finished > response in the order they came in. You can also have as many open > connections as you like - but what is missing, if I understood correctly, is > an API that fetches the responses from more than one connection at once, like > > resp = wget_http_get_response(conn1, conn1, ..., NULL); > > Now there is also a TCP+SSL API (used by the above mentioned high level > functions). This API is works asynchronously. It is like > > tcp = wget_tcp_init() > ... set all kind of configurations to the 'tcp' handle ... > err = int wget_tcp_connect(tcp, host, port) // returns immediately > wget_tcp_write() // returns after timeout or immediately if no timeout > wget_tcp_read() // returns after timeout or immediately if no timeout > wget_tcp_close() > wget_tcp_deinit() > > Internally, this API uses select/poll, but just uses a single 'tcp' handle. > > Now, what a "multi" API basically would look like is e.g. > > a function wget_tcp_select(array of tcp handles, timeout) which can be called > in a loop and which returns an array of "ready" tcp handles (ready for write > or read, configurable per tcp handle). > > > For me it looks like this is straight forward to implement (depends on the > details / requirements). > > > Internally, wget_ready_2_transfer(int fd, int timeout, int mode) in > io.c just needs a companion function that takes a list/array of fds. > > If there really is interest from the GNUnet community, why not open an issue > at https://gitlab.com/gnuwget/wget2/issues to discuss the details and the > needs. Once we agree upon the details, the implementation can be done by > anyone - whoever likes to pick it up. Greetings, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 4th September, 8 PM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 4th September, 8 PM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 20:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 20:00 this sun' Cheers, Bastian Schmidt
Re: GNUnet Monthly Meeting Sunday, 6th August, 8 PM Paris/Berlin/Rome
Dear all, I'm sorry, that correction becomes necessary: Meeting day, 1st Sunday of the month, in August is the 7th - not the 6th. This flaw is fixed in the pad. Cheers, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Datum: 02.08.2022 18:24:44 An: gnunet-developers@gnu.org Betreff: GNUnet Monthly Meeting Sunday, 6th August, 8 PM Paris/Berlin/Rome > Dear all, > > > quick reminder for our monthly meeting on > > Sunday, 6th August, 8 PM Paris/Berlin/Rome > > on mumble server: gnunet.org > > everyone is very invited! > > Pad for meeting minutes and possible agenda: > > https://pep.pad.foebud.org/GNUnet-jour-fixe > > To see the meeting start time in your time zone, run this in GNU Bash, > > date --date='TZ="Europe/Rome" 20:00 this sun' > > or in GNU Emacs type, > > M-! > > followed by, > > date --date='TZ="Europe/Rome" 20:00 this sun' > > > Cheers, > Bastian Schmidt > > > >
GNUnet Monthly Meeting Sunday, 6th August, 8 PM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 6th August, 8 PM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU Bash, date --date='TZ="Europe/Rome" 20:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 20:00 this sun' Cheers, Bastian Schmidt
Re: LSD uses Google Fonts
Hi community, I agree - and suggest switching to GNU FreeFont - https://www.gnu.org/software/freefont/ . It's licensed under "GNU GPLv3 or later" - https://www.gnu.org/software/freefont/license.html . Cheers, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: pukkamustard Datum: 13.07.2022 09:00:24 An: Gnunet Developers Betreff: LSD uses Google Fonts > Hi GNUnet, > > The LSD documents as published at https://lsd.gnunet.org currently use > Google Fonts. This is due to the default stylesheet used by the xml2rfc > tool. > > I think there has been some recent discussion about the legality of > using Google Fonts in Europe. Besides that, I don't think it fits with > the spirit of the GNUnet project. I suggest not using Google Fonts. > > One way of disabling usage of Google Fonts is to use a custom > stylesheet. The xml2rfc tool can be supplied a custom stylesheet with > the `-css` option. I have done this for the ERIS specification: > > https://codeberg.org/eris/spec/commit/f62d7bc04ce89cc259f385b298a3d97c1ab32173 > > > For LSD, this requires storing a custom stylesheet in every LSD repository. > > > Regards, > pukkamustard >
GNUnet Monthly Meeting Sunday, 3rd July, 8 PM Paris/Berlin/Rome
Dear all, quick reminder for our monthly meeting on Sunday, 3rd July, 8 PM Paris/Berlin/Rome on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe To see the meeting start time in your time zone, run this in GNU bash, date --date='TZ="Europe/Rome" 20:00 this sun' or in GNU Emacs type, M-! followed by, date --date='TZ="Europe/Rome" 20:00 this sun' Cheers, Bastian Schmidt
GNUnet Monthly Meeting Sunday, 5th June, 8 PM CEST
Dear all, quick reminder for our monthly meeting on Sunday, 5th June, 8 PM CEST on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
Re: Re: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET
Haha, that's quite a nice idea. What makes it interesting: It has its charme: What do governments on national and EU level, the majority of the population, and the majority of parlamentarians and wannabes including their organizations have in common? Facing personal experiences and considering scientific evaluation finding it as practically pointless, all of them want to do away with clock change at the beginning or end of daylight savings time. Yet, it doesn't happen. 'Be the change, you want to see'—in general that's always a good advice, especially in said absurd situation. Always sticking to CET would do just that. What makes it risky That would introduce a mental appointment shift, provoking mistimings: >From time to time, whenever people in Europe see the appointment information, they either can take the time number '20' literal—in sync with all the clocks around them—for their personal coordination to appear to the meeting just in time, or they can't take the number literal, depending on whether it indeed is CET currently, or not. And people from other places of the world—always in need of converting the time information to their local time—get pushed to convert to the current time by prominent web site results—so, now to use CEST, and in winter to use CET. Whatever the group decision will be, it certainly will be noted in the pad and will be put into action. Greetings, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: "Schanzenbach, Martin" Datum: 26.04.2022 21:08:52 An: hyazin...@emailn.de Betreff: Re: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET > We could just always move it to UTC+1 (=CET) while we are at it. > > > On 26. Apr 2022, at 18:37, hyazin...@emailn.de wrote: > > > > *sigh* CEST—summer time—of course, not CET. > > Sorry for that. I have put better measures in place for avoiding this > mistake in the future. > > > > --- Ursprüngliche Nachricht --- > > Von: > > Datum: 26.04.2022 18:10:16 > > An: gnunet-developers@gnu.org > > Betreff: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET > > > >> Dear all, > >> > >> quick reminder for our monthly meeting on > >> > >> Sunday, 1st May, 8 PM CET > >> > >> on mumble server: gnunet.org > >> > >> everyone is very invited! > >> > >> Pad for meeting minutes and possible agenda: > >> > >> https://pep.pad.foebud.org/GNUnet-jour-fixe > >> > >> Cheers > >> > >> Bastian Schmidt > >> > >> > >> > >> > > > > > > > >
Re: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET
*sigh* CEST—summer time—of course, not CET. Sorry for that. I have put better measures in place for avoiding this mistake in the future. --- Ursprüngliche Nachricht --- Von: Datum: 26.04.2022 18:10:16 An: gnunet-developers@gnu.org Betreff: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET > Dear all, > > quick reminder for our monthly meeting on > > Sunday, 1st May, 8 PM CET > > on mumble server: gnunet.org > > everyone is very invited! > > Pad for meeting minutes and possible agenda: > > https://pep.pad.foebud.org/GNUnet-jour-fixe > > Cheers > > Bastian Schmidt > > > >
GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET
Dear all, quick reminder for our monthly meeting on Sunday, 1st May, 8 PM CET on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
GNUnet Monthly Meeting Monday, 4th April, 8 PM CEST
Dear all, quick reminder for our monthly meeting on Monday, 4th April, 8 PM CEST on mumble server: gnunet.org everyone is very invited! Bear in mind we had time change last weekend, so now we have Central European Summer Time. Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
GNUnet Monthly Meeting Thursday, 3rd March, 8 PM CET
Dear all, quick reminder for our monthly meeting on Thursday, 3rd March, 8 PM CET on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
GNUnet Monthly Meeting Wednesday, 2nd February, 8 PM CET
Dear all, quick reminder for our monthly meeting on Wednesday, 2nd February, 8 PM CET on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
Re: Re: gnunet.org currently not online
You're welcome. It's the least I can do... the website is fully online, again, working properly now. Best regards, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Christian Grothoff Datum: 10.01.2022 14:59:06 An: gnunet-developers@gnu.org Betreff: Re: gnunet.org currently not online > Strange, seems an apt-get upgrade failed to restart apache. Fixed now. > Thanks for reporting! -Christian > > On 1/10/22 2:45 PM, hyazin...@emailn.de wrote: > > Hello, > > > > trying to visit gnunet.org fails currently. No matter if via https:// > or http:// . > > > > > > Best regards, > > Bastian Schmidt > > > > > > > >
gnunet.org currently not online
Hello, trying to visit gnunet.org fails currently. No matter if via https:// or http:// . Best regards, Bastian Schmidt
Re: Re: Idea: Owning Artworks On GNUnet using Non-Fungible Hashes
> The slightest glimpse of disastrous copy law is an optical to said ideal > frame for maximizing creativity. Of course, I mean, 'obstacle', not 'optical'. --- Ursprüngliche Nachricht --- Von: Datum: 10.01.2022 14:42:15 An: gnunet-developers@gnu.org Betreff: Re: Idea: Owning Artworks On GNUnet using Non-Fungible Hashes > My 2 cents: > > Take a look around. Your crib, the tech stuff in front of you, look down > at your clothes. Think of all the immaterial goods, which have made your > days of the past, and how much they formed you. All of that: A product of > creativity—useful and new, at the same time. > > How much do we appreciate this? Where would we be without it? Still in caves? > > > The appropriate way to appreciate is giving back by maximizing creativity. > > > But, you can't. You can't directly. It's like being spontaneous. > When someone asks you to be spontaneous, you can't by that moment. > > Creativity only can be maximized by forming the frame, in which creativity > arises. > And that frame has 2 adjusting screws: > 1. The more variety, the more tension—especially contrary, especially > contrast—there > is within a network system, the more creativity arises out of it. > 2. The more connections there are within a network system, the more creativity > arises out of it. > > So, the frame which maximizes creativity is one, where there are all kinds > of entities and all of them are directly connected with each others. It's > a place of everything and no boundaries. > > That means: It's a place where all immaterial goods are copylefted commons—not > even requiring linking a specific immaterial good to a subject, who has made > it. > The slightest glimpse of disastrous copy law is an optical to said ideal > frame for maximizing creativity. > > Best for all of us would be, if all immaterial goods including artwork is > shared, not attempted to be owned whatsoever. And not only that, on top of > that this state of freedom being defended. > > > Best regards, > Bastian Schmidt > > --- Ursprüngliche Nachricht --- > Von: carlo von lynX > Datum: 09.01.2022 17:15:18 > An: gnunet-developers@gnu.org > Betreff: Idea: Owning Artworks On GNUnet using Non-Fungible Hashes > > > As much as I notoriously doubt that the end-to-end > > encryption Whatsapp actually stops agencies from > > having any insight, I appreciate Moxie's recent dive > > into the world of Non-Fungible Tokens (NFTs): > > > > https://moxie.org/2022/01/07/web3-first-impressions.html > > > > I heard similar doubts from CCC people last summer, > > but it is good for someone to put it in strong and > > clear terms, combining it with the critique against > > federation and open standards which the secushare.org > > website has been carrying for a decade now. > > > > The following implies you read that blog post first. > > It's an interesting worthwhile read. > > > > The "Web3" is a joke, as much as the people that claim > > to be into "crypto", then even fail to put a hash of > > a piece of art into the blockchain rather than just > > somebody else's URL. > > > > Obviously while I read all of that, I thought how on > > the basis of GNUnet instead it could all work out for > > real. > > > > 1. GNUnet is *meant* to run on all devices, including > > smartphones. The phone companies may have to adapt! > > There must not arise any "platform" web services that > > run the GNUnet node for you. We switched to AGPL > > license because of this and should pressure any > > alternative implementation of GNUnet to also be > > released under Affero GPL or stricter! As soon as > > we allow nodes to be run elsewhere than on the device > > of the owner, several of our design goals are gone - > > and the article illustrates how people do not care. > > > > 2. We already have consensus protocols on top of > > GNUnet. If we add a ledger we can store the ownership > > of hashes of artworks which AFAIR also happen to be > > the handles for retrieval on gnunet-fs. > > > > 3. If we implement the social graph in secushare.org > > we can avoid using dirty proof-of-work but rather > > provide a blockchain by proof-of-having-a-life. The > > proof that you exist and have a life is the fact > > that you have a social surrounding which isn't just > > avatars you created yourself. > > > > So, whoopa, we have a new Internet with a new > > distributed Facebook/Skype replacement, a way to > > do blockchain apps without ruining the environment > > and a way to prove ownership of digital artworks. > > > > > > > > > >
Re: Idea: Owning Artworks On GNUnet using Non-Fungible Hashes
My 2 cents: Take a look around. Your crib, the tech stuff in front of you, look down at your clothes. Think of all the immaterial goods, which have made your days of the past, and how much they formed you. All of that: A product of creativity—useful and new, at the same time. How much do we appreciate this? Where would we be without it? Still in caves? The appropriate way to appreciate is giving back by maximizing creativity. But, you can't. You can't directly. It's like being spontaneous. When someone asks you to be spontaneous, you can't by that moment. Creativity only can be maximized by forming the frame, in which creativity arises. And that frame has 2 adjusting screws: 1. The more variety, the more tension—especially contrary, especially contrast—there is within a network system, the more creativity arises out of it. 2. The more connections there are within a network system, the more creativity arises out of it. So, the frame which maximizes creativity is one, where there are all kinds of entities and all of them are directly connected with each others. It's a place of everything and no boundaries. That means: It's a place where all immaterial goods are copylefted commons—not even requiring linking a specific immaterial good to a subject, who has made it. The slightest glimpse of disastrous copy law is an optical to said ideal frame for maximizing creativity. Best for all of us would be, if all immaterial goods including artwork is shared, not attempted to be owned whatsoever. And not only that, on top of that this state of freedom being defended. Best regards, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: carlo von lynX Datum: 09.01.2022 17:15:18 An: gnunet-developers@gnu.org Betreff: Idea: Owning Artworks On GNUnet using Non-Fungible Hashes > As much as I notoriously doubt that the end-to-end > encryption Whatsapp actually stops agencies from > having any insight, I appreciate Moxie's recent dive > into the world of Non-Fungible Tokens (NFTs): > > https://moxie.org/2022/01/07/web3-first-impressions.html > > I heard similar doubts from CCC people last summer, > but it is good for someone to put it in strong and > clear terms, combining it with the critique against > federation and open standards which the secushare.org > website has been carrying for a decade now. > > The following implies you read that blog post first. > It's an interesting worthwhile read. > > The "Web3" is a joke, as much as the people that claim > to be into "crypto", then even fail to put a hash of > a piece of art into the blockchain rather than just > somebody else's URL. > > Obviously while I read all of that, I thought how on > the basis of GNUnet instead it could all work out for > real. > > 1. GNUnet is *meant* to run on all devices, including > smartphones. The phone companies may have to adapt! > There must not arise any "platform" web services that > run the GNUnet node for you. We switched to AGPL > license because of this and should pressure any > alternative implementation of GNUnet to also be > released under Affero GPL or stricter! As soon as > we allow nodes to be run elsewhere than on the device > of the owner, several of our design goals are gone - > and the article illustrates how people do not care. > > 2. We already have consensus protocols on top of > GNUnet. If we add a ledger we can store the ownership > of hashes of artworks which AFAIR also happen to be > the handles for retrieval on gnunet-fs. > > 3. If we implement the social graph in secushare.org > we can avoid using dirty proof-of-work but rather > provide a blockchain by proof-of-having-a-life. The > proof that you exist and have a life is the fact > that you have a social surrounding which isn't just > avatars you created yourself. > > So, whoopa, we have a new Internet with a new > distributed Facebook/Skype replacement, a way to > do blockchain apps without ruining the environment > and a way to prove ownership of digital artworks. > > >
GNUnet December Meeting/GNUnet e.V. General Assembly 2021 (online) Sunday, 12th December, 8 PM CET
Dear all, quick reminder: Our upcoming December online meeting will be something special—the GNUnet e.V. General Assembly 2021. It will take place on Sunday, 12th December, 8 PM CET—just as regular monthly meetings would do— on mumble server: gnunet.org everyone is very invited! The statute allows members of GNUnet e.V. to send the board of directors proposals to the agenda up until 2 weeks before the General Assembly—https://git.gnunet.org/gnunet-ev.git/tree/satzung.tex#n185 . So, deadline for that is Sunday, 28th November, 8 PM CET. Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe The next regular monthly meeting will be next year, either shortly after January 1st, or only February 2nd. Cheers Bastian Schmidt P.S.—reminder to the board of directors: According to the statute the call-up to the General Assembly will be sent electronically by the board of directors to all members of GNUnet e.V. 1 week before the General Assembly—https://git.gnunet.org/gnunet-ev.git/tree/satzung.tex#n189 .
GNUnet Monthly Meeting Thursday, 11th November, 8 PM CEST
Dear all, quick reminder for our monthly meeting on Thursday, 11th November, 8 PM CEST on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
GNUnet Monthly Meeting Wednesday, 10th October, 8 PM CEST
Dear all, quick reminder for our monthly meeting on Sunday, 10th October, 8 PM CEST on mumble server: gnunet.org everyone is very invited! Pad for meeting minutes and possible agenda: https://pep.pad.foebud.org/GNUnet-jour-fixe Cheers Bastian Schmidt
GNU Anastasis press release of September 29, 2021 badly linked by Planet GNU: Fixable on our site?
Hello, 2 issues: 1. When you visit https://www.gnu.org/ today and have a look at the embedded Planet GNU news window at the upper part of the site on the right, one of the three news snippets is said GNU Anastasis press release: '*GNU Anastasis v0.2.0 released*: GNU Anastasis is a Free Software protocol and implementation that allows users to securely deposit core secrets with an open set of escrow providers and to reco... ' The part between the two *'s has a clickable link, this one: https://anastasis.lu/en/news/news/2021-10.html Clicking on it doesn't lead to the teasered news, but instead to '404 Not Found nginx/1.18.0' Visiting https://planet.gnu.org/ the news snippet listed 2 times, is a bit more extended, and has more links: ' *GNU Anastasis v0.2.0 released* GNU Anastasis is a Free Software protocol and implementation that allows users to securely deposit core secrets with an open set of escrow providers and to recover these secrets if their original copies are lost. *29 September, 2021 10:00PM* #GNU Anastasis v0.2.0 released# GNU Anastasis is a Free Software protocol and implementation that allows users to securely deposit core secrets with an open set of escrow providers and to recover these secrets if their original copies are lost. #29 September, 2021 10:00PM#' The 2 parts between two *'s have the same problem as experienced with the embedded Planet GNU window on gnu.org. The 2 parts between the two #'s has a working link, leading to https://anastasis.lu/en/news/2021-10.html I thought it's useful to inform you about this flaw, because you're certainly interested in getting this news item out as good as possible and by knowing that flaw you maybe can fix it one way or another. I don't know if the wrong link is from somewhere on the GNU Anastasis website and correctly grapped by Planet GNU, or if the flaw originates from Planet GNU itself. In the first case, maybe the link can be found and fixed, in the later case, maybe GNUnet team can inform Planet GNU team, so that the Planet GNU team can fix the link - maybe for now regarding said news or sustainably so that this flaw doesn't happen again in future grapped press releases of GNU Anastasis. 2. Besides, navigating through https://anastasis.lu/ seperately to it's news section https://anastasis.lu/en/docs_news.html one discovers a news snippet to said news, but no link to the press release. Best regards, Bastian Schmidt
Re: Git server migration
Probably related: Since today connection issues arise when trying to access gnunet.org: https://gnunet.org: Firefox can't connect 'Unable to connect Firefox can’t establish a connection to the server at gnunet.org. The site could be temporarily unavailable or too busy. Try again in a few moments. If you are unable to load any pages, check your computer’s network connection. If your computer or network is protected by a firewall or proxy, make sure that Tor Browser is permitted to access the Web. [OPTION] Try again' http://gnunet.org/—with activated HTTPS Everywhere: HTTPS Everywhere stops process for warning 'HTTPS Everywhere noticed you were navigating to a non-HTTPS page, and tried to send you to the HTTPS version instead. The HTTPS version is unavailable. Most likely this site does not support HTTPS, but it is also possible that an attacker is blocking the HTTPS version. If you wish to view the unencrypted version of this page, you can still do so by disabling the 'Encrypt All Sites Eligible' (EASE) option in your HTTPS Everywhere extension. Be aware that disabling this option could make your browser vulnerable to network-based downgrade attacks on websites you visit. http://gnunet.org/ [OPTIONS] Copy URL Proceed anyway (unsafe) Disable on this site' Greetings, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: "Schanzenbach, Martin" Datum: 01.09.2021 19:20:50 An: Gnunet Developers , help-gnunet , libmicroht...@gnu.org Betreff: Git server migration > Hi, > > along with some other services, we are moving the gitolite service to another > server. > Unfortunately, we cannot move the gnunet.org domain just yet, so you may > have to change your > repository urls from g...@gnunet.org/repo to g...@git.gnunet.org/repo > ( you need to add a "git." in front of gnunet.org) > > In case this should not already work for you, please contact me. > The cgit web UI is still under construction. > > Sorry for the inconvenience. > > Martin >
Taler press release of 17 June 2021 badly linked by Planet GNU: Fixable on our site?
Hello, when you visit https://www.gnu.org/ today and have a look at the embedded Planet GNU news window at the upper part of the site on the right, one of the three news snippets is said Taler press release: ' *How to issue a privacy-preserving central bank digital currency*: We are happy to announce the publication of our policy brief on"How to issue a privacy-preserving central bank digital currenc...' The part between the two *'s has a clickable link, this one: https://taler.net/en/news/news/2021-06.html Clicking on it doesn't lead to the teasered news, but instead to '404 Not Found nginx' Visiting https://planet.gnu.org/ the news snippet is a bit more extended and has more links: 'June 16, 2021 #GNU Taler news# *How to issue a privacy-preserving central bank digital currency* We are happy to announce the publication of our policy brief on"How to issue a privacy-preserving central bank digital currency" by The European Money and Finance Forum. *16 June, 2021 10:00PM* ' The part between the two #'s has a working link, leading to https://taler.net// The both parts between two *'s have the same problem as experienced with the embedded Planet GNU window on gnu.org. Following the working link of said part between the two #'s, and scrolling down the website to the news section reveals, that the correct link to said press release is the following and, of course, finally leads to said complete news one originally got interested by the news snippets on gnu.org and Planet GNU: https://taler.net/en/news/2021-06.html I thought it's useful to inform you about this flaw, because you're certainly interested in getting this news item out as good as possible and by knowing that flaw you maybe can fix it one way or another. I don't know if the wrong link is from somewhere on the Taler website and correctly grapped by Planet GNU, or if the flaw originates from Planet GNU itself. In the first case, maybe the link can be found and fixed, in the later case, maybe GNUnet team can inform Planet GNU team, so that the Planet GNU team can fix the link - maybe for now regarding said news or sustainably so that this flaw doesn't happen again in future grapped press releases of Taler. Best regards, Bastian Schmidt
Re: Re: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again
Hello, well, there we go, great starting point... *inspecting & pondering* additionally considering Carlo's and t3sserakt's last postings, it looks to me like best probably really would be if now GNUnet people and secushare people together focus on roadmap point "TNG: Transport rewrite" - apparently this is the one remaining main issue hindering sustainable secushare development, additionally it's the next to be done point in the list, anyway, and already in active development. So, we're almost there; it's not a distant, elusive, uncertain thing in the far future. And the more developers gather their activities around this point, the faster this decisive box gets ticked. Of course, developing secushare on application level would be much more fun for you, secushare people, but consider: You need some kind of base, of fundament, of infrastructure, on which you build secushare upon. And if there wasn't something like TNG Transport, Core or CADET, then you had to do it from scratch for yourself, anyway. So, consider these things as part of secushare and a valuable head start saving you effort. @ t3sserakt: I'm a regular, still reader of the meeting protocols. My limited ressources only allow me to do irregular, small contributions to GNUnet. Things like this mediating e-mail, for example. Happy hacking, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Martin Schanzenbach Datum: 16.11.2020 02:54:49 An: hyazin...@emailn.de, gnunet-developers@gnu.org Betreff: Re: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again > On Sun, 2020-11-15 at 23:25 +0100, hyazin...@emailn.de wrote: > > hello, > > > > +1 @ what t3sserakt said. > > > > GNUnet is a project of utter importance and especially valuable. > > Secushare is a project of utter importance and especially valuable. > > > Both projects joining forces to a team up increases importance and > > value by magnitudes. > > Mutually realizing and accepting, that's why the team up happened in > > > the first place. > > We need an internet replacement; one which is the amazing tool we > > thought we have with it, before realizing what we actually have are > > > chains; one which strenghens our liberty/freedom - libre, secure, > > privacy-protecting - one which is like wings for us. > > GNUnet & secushare as a team are the best approach I've come across > > > so far for building such an internet replacement. > > That's why I support both projects wherever I can. > > > > The heated discussion in this thread gave me a lot more insight into > > > what's going on than I've known so far. Still, towards these tensions > > > I'm pretty much a by-stander. Being in this naive position, it feels > > > a bit bold to even just say anything regarding that. But I still do > > > it - just trying to help: > > If I understand that right, we wouldn't had a problem here, at all, > > > in the first place, if 3 GNUnet key components on which secushare > > development highly depends on, would be just fine: CADET, core and > > transport. > > And as I got the impression, all these 3 components are in the > > process of being revised to fit like that, but that process is a ton > > > of work and therefore lasts long. > > Development has to make fun, and has to be done fundamentally stone > > > by stone - you don't just build a roof. > > I could imagine, that a good middle ground, a good way forward would > > > be, if 2 things change: > > 1. Secushare people help GNUnet people more with development of > > CADET, core and transport. > > 2. GNUnet people focus their work more on paving the way for > > secushare people to do their secushare development in a way, which > > makes more sense, is more sustainable, and more fun. Maybe by a > > motivating one-by-one roadmap, finishing one corner stone after > > another for building a way for secushare people to move forward. > > Maybe something like, 'At first we fix core, then CADET, and then > > transport, and then all obstacles for secushare development are our > > > of the way!'. > > We do have a "hidden" roadmap (not 100% up to date anymore): > https://gnunet.org/en/roadmap.html > > And the detailed issues can be found in mantis. The sheer number is > overwhelming though. Maybe I will update and publish the roadmap and > link it to mantis tags at some point. > > BR > > > > > > > We gotta hold together, that's what makes us strong, and appreciate > > > eath other, > > Bastian Schmidt > > > > > > --- Ursprüngliche Nachricht --- > > Von: t3sserakt > > Datum: 15.11.2020 11:14:09 > > An: gnunet-developers@gnu.org > > Betreff: Re: Open questions regarding new messenger and secushare > > and organization Was: Make GNUnet Great Again > > > > > On 15.11.20 10:13, carlo von lynX wrote: > > > > On Fri, Nov 13, 2020 at 12:36:21PM +0100, Christian Grothoff > > > > > wrote: > > > > > > > > > - Is "messenger" a part of "secushare"? > > > > > > > > > In my view, it's a fresh attempt to build
Re: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again
hello, +1 @ what t3sserakt said. GNUnet is a project of utter importance and especially valuable. Secushare is a project of utter importance and especially valuable. Both projects joining forces to a team up increases importance and value by magnitudes. Mutually realizing and accepting, that's why the team up happened in the first place. We need an internet replacement; one which is the amazing tool we thought we have with it, before realizing what we actually have are chains; one which strenghens our liberty/freedom - libre, secure, privacy-protecting - one which is like wings for us. GNUnet & secushare as a team are the best approach I've come across so far for building such an internet replacement. That's why I support both projects wherever I can. The heated discussion in this thread gave me a lot more insight into what's going on than I've known so far. Still, towards these tensions I'm pretty much a by-stander. Being in this naive position, it feels a bit bold to even just say anything regarding that. But I still do it - just trying to help: If I understand that right, we wouldn't had a problem here, at all, in the first place, if 3 GNUnet key components on which secushare development highly depends on, would be just fine: CADET, core and transport. And as I got the impression, all these 3 components are in the process of being revised to fit like that, but that process is a ton of work and therefore lasts long. Development has to make fun, and has to be done fundamentally stone by stone - you don't just build a roof. I could imagine, that a good middle ground, a good way forward would be, if 2 things change: 1. Secushare people help GNUnet people more with development of CADET, core and transport. 2. GNUnet people focus their work more on paving the way for secushare people to do their secushare development in a way, which makes more sense, is more sustainable, and more fun. Maybe by a motivating one-by-one roadmap, finishing one corner stone after another for building a way for secushare people to move forward. Maybe something like, 'At first we fix core, then CADET, and then transport, and then all obstacles for secushare development are our of the way!'. We gotta hold together, that's what makes us strong, and appreciate eath other, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: t3sserakt Datum: 15.11.2020 11:14:09 An: gnunet-developers@gnu.org Betreff: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again > On 15.11.20 10:13, carlo von lynX wrote: > > On Fri, Nov 13, 2020 at 12:36:21PM +0100, Christian Grothoff wrote: > > >>> - Is "messenger" a part of "secushare"? > > >> In my view, it's a fresh attempt to build something that might be > > >> considered part of / become part of the secushare vision. That said, > I > >> think its premature given that messenger clearly is still evolving, > and > >> secushare remains largely vaporware > >> (Secushare-people: do correct me if I am wrong here). > > Well, GNUnet remains largely vaporware and each time we tried to get > > > a minor thing working in secushare we ran into fundamental issues on > > > the GNUnet level that needed addressing first… your public announcement > > > for 0.14 still provides no guarantees that CADET, core and transport > > > will do their jobs - although nearly nothing can be built on top while > > > that isn't the case. > > > >> That's the key point: if someone maintains it, it can come back. > > > How can you expect that we maintain a project that would be a kind > > of Facebook replacement if the replacement for HTTPS still isn't > > reliably working? On the contrary, since you lured us into writing > so > > much code for a dysfunctional framework underneath, I consider it > > your social reponsibility to keep the code up to date through *your* > > > API changes, and not us! *You* should maintain secushare! And do the > > > best to motivate us to come back and work for you. We invested years > > > into YOUR project and you call US vaporware after all of that? > > As someone started joining secushare before working on GNUnet I like to > remember everybody here that in the end it makes no difference to > distinguish between secushare or GNUnet being vaporware, because we all > > want to fix the same problem! > > Calling secushare vapoware is not wrong, but it was no good idea to do > so, without to be clear about the reasons for that! > > From the release 0.14.0 news item: > > "*only suitable for early adopters with some reasonable pain tolerance"* > > > It is not only users, but also developers who need to have pain > tolerance, because this is no sprint but a marathon to get things > working. Our main problem is still resources, because it is not easy to > find developers with the needed expertise and pain tolerance who want to > > work as a volunteer or for less money they could get working for some > company with a lot of money. > > So
Re: GNUnet 0.14.0 released
Hello, as this is a major release: Let me remind you to make sure that this important news item gets posted on the info-gnu mailing list, too: https://lists.gnu.org/archive/html/info-gnu/ Hasn't happened so far, yet: https://www.gnu.org/software/recent-releases.html Reasoning: New version publications can and should be used as great project promotion impulses. This way project outreach improves - potentially more people take notice of the project and turn to it. Best regards, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Martin Schanzenbach Datum: 14.11.2020 09:47:34 An: Gnunet Developers , info-gnu...@gnu.org, help-gnunet Betreff: GNUnet 0.14.0 released > We are pleased to announce the release of GNUnet 0.14.0. > > This is a new major release. It breaks protocol compatibility with the > 0.13.x versions. Please be aware that Git master is thus henceforth > INCOMPATIBLE with the 0.13.x GNUnet network, and interactions between > old and new peers will result in issues. 0.13.x peers will be able to > communicate with Git master or 0.13.x peers, but some services - in > particular GNS - will not be compatible. > In terms of usability, users should be aware that there are still a > large number of known open issues in particular with respect to ease of > use, but also some critical privacy issues especially for mobile users. > > Also, the nascent network is tiny and thus unlikely to provide good > anonymity or extensive amounts of interesting information. As a result, > the 0.14.0 release is still only suitable for early adopters with some > reasonable pain tolerance. > > Download links: > > http://ftpmirror.gnu.org/gnunet/gnunet-0.14.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-0.14.0.tar.gz.sig > http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.14.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.14.0.tar.gz.sig > http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.14.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.14.0.tar.gz.sig > > The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A > > Note that due to mirror synchronization, not all links might be > functional early after the release. For direct access try > http://ftp.gnu.org/gnu/gnunet/ > > Noteworthy changes in 0.14.0 (since 0.13.3) > > GNS: > - Aligned with specification LSD001. > - Crypto agility: The GNS protocol now supports other zone types > besides ECDSA-based PKEYs. However, the alternative EdDSA-based EDKEY > crypto is not yet implemented. #6485 > - PKEY zones: ECDSA zone record sets are now encrypted using AES-CTR. > > #6487 > IDENTITY: Identities can now be created either as ECDSA (default) or > EdDSA key pairs. > POSTGRESQL: Allow NULL value returns and fix test cases. #6524 > UTIL: String time conversion functions no longer localized to preserve > reversibility. #6615 > Buildsystem: README updates to clarify runtime/compile/optional > dependencies > (NEW) MESSENGER: New messenger component (experimental) > > A detailed list of changes can be found in the ChangeLog and the 0.14.0 > bugtracker at https://bugs.gnunet.org/changelog_page.php?project_id=13. > > > Known Issues > > - There are known major design issues in the TRANSPORT, ATS and CORE > subsystems which will need to be addressed in the future to achieve > acceptable usability, performance and security. > - There are known moderate implementation limitations in CADET that > negatively impact performance. > - There are known moderate design issues in FS that also impact > usability and performance. > - There are minor implementation limitations in SET that create > unnecessary attack surface for availability. > - The RPS subsystem remains experimental. > - Some high-level tests in the test-suite fail non-deterministically > due > to the low-level TRANSPORT issues. > > In addition to this list, you may also want to consult our bug tracker > at bugs.gnunet.org which lists about 190 more specific issues. > > Thanks: > This release was the work of many people. The following people > contributed code and were thus easily identified: Christian Grothoff, > Daniel Golle, t3sserakt, TheJackiMonster and Martin Schanzenbach. > >
Re: GNUnet 0.13.0 released
Hello, this important news item hasn't appeared on the info-gnu mailing list, yet: https://lists.gnu.org/archive/html/info-gnu/2020-07/threads.html A look into the info-gnu mailing list archive reveals that news of previous GNUnet version publications did appear on this mailing list - the last one was GNUnet 0.12.0, on Fri, 20 Dec 2019 10:28:59 +0900: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GNUnet=Search%21=info-gnu=20=normal=date%3Alate And interestingly, looking into GNUnet-dev mailing list archive, at the same moment as on GNUnet-dev mailing list: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=+GNUnet+0.12.0+released=Search%21=gnunet-developers=20=normal=score Smells like something got broken in the meantime, doesn't it? It would be great, if anyone can fix this. Reasoning: New version publications can and should be used as great project promotion impulses. This way project outreach improves - potentially more people take notice of the project and turn to it. Best regards, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: "Schanzenbach, Martin" Datum: 07.07.2020 19:49:12 An: Gnunet Developers , info-gnu...@gnu.org, help-gnunet Betreff: GNUnet 0.13.0 released > We are pleased to announce the release of GNUnet 0.13.0. > > We are pleased to announce the release of GNUnet 0.13.0. > This is a new major release. It breaks protocol compatibility with > the 0.12.x versions. Please be aware that Git master is thus > henceforth INCOMPATIBLE with the 0.12.x GNUnet network, and interactions > > between old and new peers will result in signature verification failures. > > 0.12.x peers will NOT be able to communicate with Git master or 0.13.x peers. > > In terms of usability, users should be aware that there are still a large > > number of known open issues in particular with respect to ease of use, but > > also some critical privacy issues especially for mobile users. Also, the > > nascent network is tiny and thus unlikely to provide good anonymity or > extensive amounts of interesting information. As a result, the 0.13.0 > release is still only suitable for early adopters with some reasonable pain > > tolerance. > > Download links: > > http://ftpmirror.gnu.org/gnunet/gnunet-0.13.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-0.13.0.tar.gz.sig > http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.13.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.13.0.tar.gz.sig > http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.13.0.tar.gz > http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.13.0.tar.gz.sig > > The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A > > Note that due to mirror synchronization, not all links might be > functional early after the release. For direct access try > http://ftp.gnu.org/gnu/gnunet/ > > Noteworthy changes in 0.13.2 (since 0.12.2): > > GNS: > - Aligned with specification LSD001. > - NSS plugin "block" fixed. #5782 > - Broken set NICK API removed.#6092 > - New record flags: SUPPLEMENTAL. Records which are not explicitly >configured/published under a specific label but which are still >informational are returned by the resolver and flagged accordingly. #6103 > > - gnunet-namestore now complains when adding TLSA or SRV records >outside of a BOX > > CADET: Fixed tunnel establishment as well as an outstanding bug regarding > >tunnel destruction. #5822 > > GNS/REVOCATION: Revocation proof of work has function changed to argon2 > and modified to reduce variance. > RECLAIM: Increased ticket length to 256 bit. #6047 > > TRANSPORT: UDP plugin moved to experimental as it is known to be unstable. > > > UTIL: > - Serialization / file format of ECDSA private keys harmonized with other > >libraries. Old private keys will no longer work! #6070 > - Now using libsodium for EC cryptography. > - Builds against cURL which is not linked against gnutls are now possible > >but still not recommended. Configure will warn that this will impede the > >GNS functionality. This change will make hostlist discovery work more > >reliable for some distributions. > - GNUNET_free_non_null removed. GNUNET_free changed to not assert that the > >pointer is not NULL. For reference see the Taler security audit. > - AGPL request handlers added GNUnet and extension templates. > > (NEW) GANA Registry: We have established a registry to be used for names > and > numbers in GNUnet. This includes constants for protocols > > including GNS record types and GNUnet peer-to-peer > messages. > > See https://gana.gnunet.org/. > (NEW) Living Standards: LSD subdomain and LSD0001 website: LSD0001 > > (NEW) Continuous integration: https://buildbot.gnunet.org/ is back. > > Buildsystem: A significant number of build system changes: > - libmicrohttpd and libjansson are now required dependencies. > - New dependency: libsodium. > - Fixed an issue with libidn(2)
Re: Re: New front matter
Hello, > > On 3. Jul 2020, at 18:34, hyazin...@emailn.de wrote: > > > > Hello, > > > > > > 1st impression: > > Fantastic. Clear improvement. > > Engage butten needs to be bigger, adopting same form as every other > button in the row, in the course of that place icon in 1st row of the button > and the text Engage right below in the 2nd row of the button, just like it's > been done in case of the Applications button. > > > Thanks. > > the text (the icon is also just text) simply breaks line depending on the > resolution. On my screens, it was always in a single line. > Should be fixed now hopefully, but button height will still differ on very > small screens. > > BR Well, it is fixed by now - just as recommended. And it's better like that. *clicking applications button, getting to https://stage.gnunet.org/en/applications.html * Oh, awesome, and then all applications with their distinctive logos! Well, not all, but in general, and that's a good thing all applications should strife for. That general approach looks more exciting and conveys so much better, that GNUnet is the frame, the playing field, and within it for the things we wanna do are the applications, like players on that field. But one thing could be made better: This sub page feels like a dead end street, because it misses the button row of the previous site from where I came from. It would be better, if the button row is also on the sub pages, but the respective button in that row linking to that sub page respectively greyed out or so. In other words: Main page, all buttons blue, application sub site, all buttons blue, except the application button, which is greyed out or anyhow else different than the other buttons, to show, that the target of the application button is already reached by looking at this specific sub page. And regarding the main page logo evaluation of Nikita: Twitter bird? Striking point. It's because the general design approach for this icon class 'GNUnet solution' - simple, bright blue - let's every bird silouette look like the twitter bird - unless: One could use a dove with a small tree branch in its mouth. This way the freedom icon would build up enough difference to the twitter logo to not revoke this association. Aside of that I made a round thinking about how the logos could be better, but I couldn't come up with anything better. Bastian Schmidt > > 2nd impression: > > Just confirmation of 1st impression, and noticing the beauty of the > changes: The wall of text is broken up into easily digestable chunks, the > comparison of problematic aspects and GNUnet's solutions to it clearer worked > out, including visualized by contrasting section backgrounds and icons. Last > but not least my gut feeling tells me, that these changes additionally fix > some of the issues uncovered by the very valuable accessibility > > assessment done by Accessibility Foundation - > > https://lists.gnu.org/archive/html/gnunet-developers/2020-02/msg00012.html > . > > > > Conclusion: Adoption recommended. > > > > > > I hope this feedback helps, > > Bastian Schmidt > > > > --- Ursprüngliche Nachricht --- > > Von: "Schanzenbach, Martin" > > > Datum: 03.07.2020 13:42:01 > > An: Gnunet Developers > > Betreff: New front matter > > > >> Hi, > >> > >> based on the feedback from the online hacker days I updated the > frontpage > >> on https://stage.gnunet.org. > >> Feedback welcome. Also wrt content. > >> > >> BR > >> Martin > >> > > > > > >
Re: New front matter
Hello, 1st impression: Fantastic. Clear improvement. Engage butten needs to be bigger, adopting same form as every other button in the row, in the course of that place icon in 1st row of the button and the text Engage right below in the 2nd row of the button, just like it's been done in case of the Applications button. 2nd impression: Just confirmation of 1st impression, and noticing the beauty of the changes: The wall of text is broken up into easily digestable chunks, the comparison of problematic aspects and GNUnet's solutions to it clearer worked out, including visualized by contrasting section backgrounds and icons. Last but not least my gut feeling tells me, that these changes additionally fix some of the issues uncovered by the very valuable accessibility assessment done by Accessibility Foundation - https://lists.gnu.org/archive/html/gnunet-developers/2020-02/msg00012.html . Conclusion: Adoption recommended. I hope this feedback helps, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: "Schanzenbach, Martin" Datum: 03.07.2020 13:42:01 An: Gnunet Developers Betreff: New front matter > Hi, > > based on the feedback from the online hacker days I updated the frontpage > on https://stage.gnunet.org. > Feedback welcome. Also wrt content. > > BR > Martin >
Re: NGI Pointer application
Hello, trying to help, as usual: 1. > ### Impact 2 Open source contributions (1000c): > > We will release all documentation, specification, source code, test > cases and benchmarking tools under the GNU Affero General Public License > > and/or Creative Commons License where applicable. We will contribute to > > and engage with the standardization process of the IETF trust under the > canonical public license for RFCs. We will also submit proposals for > talks about the project to European hacker and tech conferences. Improvement suggestion with a few changes here and there: "### Impact 2—contributions to the commons (1000c): We will release all documentation, specification, source code, test cases, and benchmarking tools under "GNU Affero General Public License, version 3 or any later version" and/or Creative Commons License where applicable. This way said resources paid by the people are given to and stay in the hands of the people; so, all members of society are and stay free to use, copy, distribute, study, change, and improve said resources. We will contribute to and engage with the standardization process of the IETF trust under the canonical public license for RFCs. We will also submit proposals for talks about the project to European hacker and tech conferences." Reasoning: + More emphasis on the benefit from regulators' perspective in easy to understand words and explanation in headline and text + Practical license clarification, implicitely highlighting that the projects' license approach protects user's freedom even better 2. > ### Team motivation (500c): > > Bernd Fix has been involved with a privacy-preserving Internet as part > of his duties at the Wau Holland foundation, which supports research, > development and education in this domain. Bernd has been instrumental in > > furthering the standardization process for the GNU Name System, an > privacy-enhanced alternative to DNS. DHTs play a crucial role for > performance, availability and privacy in many P2P architectures, > motivating Bernd to work on improving the state of the art in this > important domain. Improvement suggestion: "...furthering the standardization process for the GNU Name System, a privacy-enhanced alternative to DNS." Reasoning: Typo fix—"a", not "an" Regards, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Bernd Fix Datum: 28.05.2020 19:56:51 An: gnunet-developers@gnu.org Betreff: NGI Pointer application > Hi all. > > Last year we (Martin, Christian and I) successfully applied for a NGI > Discovery grant (through NLnet) to write an RFC draft and to > re-implement GNS in Golang (as well as some GNUnet packaging for > distros) - which worked out pretty well and improved GNUnet crypto and > other things. > > We are now in the process of re-applying for a NGI Pointer grant; the > idea is to do the same thing for the DHT. As the grant is covering for > much more work, we would like more people to participate. > > If you are interested in joining the application, we would be happy to > receive your input. What we basically need as information is the following: > > > - Name: > - Gender: (m/f/d/-) > - Role/Responsibility: (what you can/want to do, see section below) > - CV/Background: (link or pdf) > - Commitment: (How much time you can spend over the next 12 month) > > Please read the following text we are going to apply with; if you are > interested in joining, we need your reply as soon as possible (latest is > > Saturday noon) as we have to submit the application by then. > > I apologize that this is on very short notice; we thought it would be > sufficient to apply as GNUnet e.V. and sort out the task assignment > later, but decided it would improve our chances of getting accepted if > we list people that want to participate in application itself. > > Of course we are just applying and there is no garantee that we will get > > funded - but chances are not that bad after our last successful project... > > > Regards, Bernd. > > - > > # DHT > > ## Basic Information > > ### Name > > R5N-DHT > > ## Project > > ### Tagline (280c) > > Specifying and implementing a resilient DHT: Enabling new concepts for > decentralized name resolution, network governance and content management > > through distributed privacy-preserving and censorship-resistant > key-value stores. > > ### Brief description (1000c) > > Tomorrows internet will still have to rely and run on todays physical > infrastructure which at its core is hierarchically organized, owned and > operated by just a few global actors. Decentralization is therefore > becoming a major building block to strengthen the values of freedom and > > informational self-determination against the particular interests of > such actors that are not driven by the idea of the commons, but by > for-profit or nationalist interests. Distributed Hash Tabes (DHTs) are > at the foundation of many of these new decentralized
Re: [GNUnet-developers] EcDSA signature scheme
Thank you for the evaluation and info. The combination thing sounds familiar to me. I'm reminding that I've heard of that before in a crypto talk anywhere... --- Ursprüngliche Nachricht --- Von: Christian Grothoff Datum: 12.08.2018 23:33:29 An: gnunet-developers@gnu.org Betreff: Re: [GNUnet-developers] EcDSA signature scheme > This does not sound like a great idea, largely because the PQ algorithms > > are all a bit new and not nearly as well understood as classical crypto. > > A sane PQ implementation should _combine_ classical and PQ crypto, i.e. > sign/verify with both types of algorithms and for encryption use two > types of KX algorithms and then HKDF the results together. As they are > > not doing that (at least nothing in their documentation suggests this), > I would advise to stay away. > > Also, as far as GNUnet is concerned, Jeff is planning on putting some PQ > > crypto into the Lake design, and I'm don't see an urgent need to deploy > PQ elsewhere yet. But having good PQ crypto primitive implementations > out there would definitively be a good thing, but I'm not sure codecrypt > > is where I'd look. ;-) > > On 08/12/2018 06:44 PM, hyazin...@emailn.de wrote: > > News on the PQ site of things - at least worth it to keep an eye on: > > > Whonix includes Codecrypt by default now - > > https://www.whonix.org/wiki/PQCrypto#Use_Instructions > . > > Codecrypt is a GnuPG-like unix program for encryption and signing that > uses only quantum-computer-resistant algorithms. It's Free Software using > "GNU LGPLv3 or later" license, which is good. Codecrypt git: > https://gitea.blesmrt.net/exa/codecrypt > > > > > > ___ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers > ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] EcDSA signature scheme
News on the PQ site of things - at least worth it to keep an eye on: Whonix includes Codecrypt by default now - https://www.whonix.org/wiki/PQCrypto#Use_Instructions . Codecrypt is a GnuPG-like unix program for encryption and signing that uses only quantum-computer-resistant algorithms. It's Free Software using "GNU LGPLv3 or later" license, which is good. Codecrypt git: https://gitea.blesmrt.net/exa/codecrypt Greetings, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Datum: 14.07.2018 11:00:50 An: Bernd Fix Betreff: Re: [GNUnet-developers] EcDSA signature scheme > *Disclaimer: I'm not skillful in cryptography. I hope you can tolerate random > input with intention to help GNUnet crypto in general. I hope that the input > is helpful in any case and sorry if the input is not helpful in any case. > More eyes see more. Sometimes also including the unskillful ones.* > > When it comes to double application/hashing after the 1st round of it one > should do "Xor" or in other words 'push down a bit/swap a bit/change > a bit' > > Nonce always have to be different and in being so unique - without any > exception. > > What crypto in general to use: > 1. MRAE - (nonce)-misuse-resistant-authenticated-encryption: > Especially RIV - Robust Initialization Vector - > https://www.researchgate.net/publication/305421597_RIV_for_Robust_Authenticated_Encryption > otherwise SIV - Synthetic Initialization Vector > But the downside of it is that it's slow/effortful, because it has to go > over cleat text for 2 times > So, this crypto is not suitable for realtime applications/streaming > But it's the most secure crypto. > 2. Robust authenticated encryption: > If one is dealing with realtime applications/streaming, one should go down > one step > from MRAE to this Robust authenticated encryption. > Especially POET is a good choice, that's the successor generation of McOE-G. > Otherwise McOE-G or maybe COLM is a good pick. > That's the 2nd most secure crypto. > > But in times of quantum computers - by 2018 NSA could have a decent one > - it's probably better to increasingly consider Post-Quantum Cryptography > (PQCrypto), because then ECDSA and ECDH are also no longer secure anymore. > I found this page to be useful for overview: > https://www.whonix.org/wiki/PQCrypto > . > For more details this page is very good: https://pqcrypto.org/ > Did you know that the TOR project planned to migrate to quantum resistant > ciphers by version 0.2.9.x ( > https://trac.torproject.org/projects/tor/ticket/17286 > + https://trac.torproject.org/projects/tor/ticket/24985 ) ? But my impression > is, that they've done the fatal mistake to postpone this to a far, far, > undefined > point in the future. > > > Greetings, > Bastian Schmidt > > --- Ursprüngliche Nachricht --- > Von: Bernd Fix > Datum: 13.07.2018 11:26:44 > An: gnunet-developers@gnu.org > Betreff: Re: [GNUnet-developers] EcDSA signature scheme > > > I think that most problems mentioned in my previous post originate in > > the '#define CURVE "Ed25519"' statement at curve_ecc.c:37. > All > > key > > parameter definitions (EdDSA, ECDSA and ECDHE) use that value leading > to > > > > the described problems. I think that the curve key parameter needs to > be > > > > set individually for each purpose. > > > > I have created a new branch "new_crypto" to collect the changes > > I see > > fit for the EC crypto stuff. I hope to be able to push it later today > > (if not, I will not be able to do so before next Wednesday). > > > > As more changes in crypto are pending (iirc it was mentioned that the > > timestamp will be removed from the HMAC computation), we could collect > > these changes in that new branch. > > > > Any suggestions or comments? > > > > ___ > > GNUnet-developers mailing list > > GNUnet-developers@gnu.org > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > > > > ___ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] New README.md and Github
Hello, I think that all interests publicly stated here aren't too far away from each other and form a common notion, which everyone probably can live with in practice: Fundamental: 1. Living Free Software consequently is important. 2. Outreach/building a 'bridge' to others is important for community growth. 3. More Accessibility is good for point 2, also in form of more user friendly descriptions. Consequences: Officially GNUnet keeps relying on self-hosting and staying away from GitHub. Inofficially individuals, who feel the need for GNUnet to be accessible over GitHub, are free to create a GitHub mirror, but are recommended to not just build a simple 'bridge', but design it's descriptions and functionality in a way, which makes it more attractive for visitors of the GitHub mirror, to turn to the self-hosted infrastructure of the GNUnet project. The GNUnet project keeps working at becoming more user friendly and accessible, and individuals feeling the need for GNUnet to go into this direction including the ones with interest in GNUnet presence on GitHub are recommended to rather put their appreciated efforts into improving key project-public-interfaces like the new upcoming website, the documentation, and the README file than creating said GitHub mirror. Please consider: - If you use GitHub, you contribute to a certain amount to making GitHub the norm - no matter how you use GitHub - GitHub structurally works against Free Software: GNUnet is licensed GNU AGPLv3orlater, but it's not possible to make GitHub website template say so. It just lets you say 'GNU AGPLv3', lets the 'orlater' part drop. So in disfavor of the GNUnet project, everyone interested in GNUnet project, and the Free Software movement practically important license clarification is reduced, especially regarding code sharing capability of GNUnet code with project code of projects using a new AGPL versions, in case there ever will be a release of a new AGPL version - GitHub belongs to Microsoft. Practically, next to Facebook, Google, and Twitter, Microsoft is an arm of the NSA by the NSA's PRISM program. Greetings, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Christian Grothoff Datum: 02.08.2018 19:07:05 An: gnunet-developers@gnu.org Betreff: Re: [GNUnet-developers] New README.md and Github > https://www.gnu.org/prep/maintain/maintain.html#Freedom-for-Web-Pages is > > very clear on this: "If you use a site other than www.gnu.org, please > > make sure that the site runs on free software alone." > Note that there is no policy against individuals creating GitHub mirrors > > of our master Git repository, just as a GNU package we shall not create > any official mirror there. ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] EcDSA signature scheme
*Disclaimer: I'm not skillful in cryptography. I hope you can tolerate random input with intention to help GNUnet crypto in general. I hope that the input is helpful in any case and sorry if the input is not helpful in any case. More eyes see more. Sometimes also including the unskillful ones.* When it comes to double application/hashing after the 1st round of it one should do "Xor" or in other words 'push down a bit/swap a bit/change a bit' Nonce always have to be different and in being so unique - without any exception. What crypto in general to use: 1. MRAE - (nonce)-misuse-resistant-authenticated-encryption: Especially RIV - Robust Initialization Vector - https://www.researchgate.net/publication/305421597_RIV_for_Robust_Authenticated_Encryption otherwise SIV - Synthetic Initialization Vector But the downside of it is that it's slow/effortful, because it has to go over cleat text for 2 times So, this crypto is not suitable for realtime applications/streaming But it's the most secure crypto. 2. Robust authenticated encryption: If one is dealing with realtime applications/streaming, one should go down one step from MRAE to this Robust authenticated encryption. Especially POET is a good choice, that's the successor generation of McOE-G. Otherwise McOE-G or maybe COLM is a good pick. That's the 2nd most secure crypto. But in times of quantum computers - by 2018 NSA could have a decent one - it's probably better to increasingly consider Post-Quantum Cryptography (PQCrypto), because then ECDSA and ECDH are also no longer secure anymore. I found this page to be useful for overview: https://www.whonix.org/wiki/PQCrypto . For more details this page is very good: https://pqcrypto.org/ Did you know that the TOR project planned to migrate to quantum resistant ciphers by version 0.2.9.x ( https://trac.torproject.org/projects/tor/ticket/17286 + https://trac.torproject.org/projects/tor/ticket/24985 ) ? But my impression is, that they've done the fatal mistake to postpone this to a far, far, undefined point in the future. Greetings, Bastian Schmidt --- Ursprüngliche Nachricht --- Von: Bernd Fix Datum: 13.07.2018 11:26:44 An: gnunet-developers@gnu.org Betreff: Re: [GNUnet-developers] EcDSA signature scheme > I think that most problems mentioned in my previous post originate in > the '#define CURVE "Ed25519"' statement at curve_ecc.c:37. All > key > parameter definitions (EdDSA, ECDSA and ECDHE) use that value leading to > > the described problems. I think that the curve key parameter needs to be > > set individually for each purpose. > > I have created a new branch "new_crypto" to collect the changes > I see > fit for the EC crypto stuff. I hope to be able to push it later today > (if not, I will not be able to do so before next Wednesday). > > As more changes in crypto are pending (iirc it was mentioned that the > timestamp will be removed from the HMAC computation), we could collect > these changes in that new branch. > > Any suggestions or comments? > > ___ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers > ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] logo rework
--- Ursprüngliche Nachricht --- Von: carlo von lynX Datum: 26.06.2018 21:45:38 An: gnunet-developers@gnu.org Betreff: Re: [GNUnet-developers] logo rework >> I'm wondering a bit about the text not being 'GNUnet', but 'gnu:net'. Wasn't >> consensus in case of text application, that it should be 'GNUnet'? > Interestingly you're the first to bring this up. I think that > "GNUnet" works well to make it stand out in a written text but > it does not look exactly beautiful and elegant when used stand- > alone as a graphic imagery. If it *really* has to be GNUnet, > then one can put "GNU" in smallcaps so it fits the size of the > "net". But I've done this before and wasn't really convinced. I don't have any hard feelings about that. Just noticed the switch and draw attention to it, so that all notice it. If there was a vote on what specific way to write GNUnet in the logo - upper case, lower case, all upper case, all lower case, mixes, etc. - I could pick up dices for my decision. But maybe that's just because I'm not very skillful in typography. Btw, screenshot of 'GNU' in smallcaps: https://abload.de/img/writing-lowercaseuppet9jcs.png > When doing graphical versions of the name I prefer either all > caps (GNUNET) or lowercase. The colon in-between came to be as > the dots were almost identical to the ones used in the logo > itself.. that's how I chose to use two actual gnunet nodes > from amirouche's design and positioned them to form the colon > in the text, so it's technically no longer a colon. ;) Yeah, that's a beautiful thing. Definitely liked that design step. > Something that captures my interest about lowercase "gnu:net" is > how the "u:n" looks mirrored.. I can imagine animations that play > with whirling the text in circles while the u:n always lines up > nicely. We can say the animation illustrates the non-deterministic > routing of GNUnet. ;)) There's a lot of nice things you can do for animating specifically this logo. > Just because the new logo does a "gnu:net" kind of thing doesn't > make me think we are under any pressure or need to change existing > text. To me using GNUnet in written text is still fine. But it's > also no big deal to just s/GNUnet/gnu:net/g on all repos... ;) Yeah, I like this flexible handling and agree with it. > And then there was gnu.net. The domain is for sale. Yeah, that, of course, would be very nice to have. Same information within the URL, but conveyed with less signs. That would be great. >> 2. - suggestions for improvement: >> >> The network and the text look good, but the background doesn't fit so well: >> The white border distracts and when you squinch your eyes half way shut, the >> brown background turns into black. > Oh yeah, it'S the first things I changed when I did versions for > the new website couple hours ago. Great eyes see alike.. the two > versions you made are exactly the way I thought would be the > natural developments. I uploaded a black one to the website in > the making, but I would still consider the dark blue variant. Yeah, I also prefer the 'night theme'-like dark blue version. >> Both build up a brightness difference between the network and the background, >> which lets the network appear to be glowing a bit - but just a bit, not too >> flashy - which is good. > Yes, a slight glow effect might actually work, but I like how > there's already a glow happening in the viewer's brains, when > there actually isn't any. And that's the beauty of it - expressing 'anonymity/privacy preservation' - and exactly what I've meant. This passive glow, which happens just in our brains, when there actually isn't any, that's exactly what I've meant by this, not applying a real, active glow effect. A glow effect is always kind of appealing, but it's more important that it's application fits to the concrete content. GNUnet is an alternative network stack, which strives to be 'anonymous/privacy-perserving' by default, not 'hang your ass out of the window' by default. So, a network of bright lantern nodes and connections, shining in the dark, brightening near areas, would be too much attention. I mean, our nodes don't want to be a center of attention, but the opposite of it. And that's also something one should be aware of when doing an animation: It always comes so natural to let something appear with an active glow, but specifically for the GNUnet adding this wouldn't make the overall result fit more to the GNUnet, but less. However, creating a passive glow by brightness difference between the network and the background is a very good way to introduce an appealing glow and at the same time do it in a way, which makes the overall result fit even more to the GNUnet. It takes subtlety to make a glow work for the GNUnet with its fundamental architectural goals, and a glow 'happening in the viewer's brains, when there actually isn't any' takes subtlety to the next level - one that can't be increased, and extends perception
Re: [GNUnet-developers] logo rework
Hello, I have to admit: This is my 2nd attempt to send this e-mail so that you all can read it. The 1st attempt 12 hours ago seemed to fail - still haven't received my e-mail from the mailing list. I must have done mistakes in addressing, it probably must be different, because it's a response e-mail to an e-mail of this month... but I think and hope I got it now... whatever... 2 things: A basic evaluation & suggestions for improvement 1. - A basic evaluation: The result of addressing the raised legal concerns by changing the shape of the gnu away from a 'V' form worked out very well. As such the 'network in shape of a gnu' logo including the text 'gnu:net' looks good. In comparison to the old logo - the comic gnu in the spider net - the 'network in shape of a gnu' is a clear improvement. New point: The logo design approach of a 'network in shape of a gnu' as such can be animated better by an 'appearance animation' than the old logo - the comic gnu in the spider net. So, in case our community starts efforts to let the GNUnet logo appear by an animation, the prospects of a good outcome as such are far better with the 'network in shape of a gnu' than with the old logo - the comic gnu in the spider net. Old point: The 'network in shape of a gnu' logo is refreshingly timeless, modern, and slick, a look mirroring what the GNUnet is: Hot shit. So, it's pleasing and just fits to the project. I'm wondering a bit about the text not being 'GNUnet', but 'gnu:net'. Wasn't consensus in case of text application, that it should be 'GNUnet'? In case of a vote and if I had a say there, I would vote in favor of changing the old logo - the comic gnu in the spider net - to this version of the 'network in shape of a gnu' posted by Lynx on 24th of june 2018 on this mailing list. 2. - suggestions for improvement: The network and the text look good, but the background doesn't fit so well: The white border distracts and when you squinch your eyes half way shut, the brown background turns into black. So, let's go dark/no-brown right away: Here are 2 variations without the white border and no brown background - a black background, and a 'night theme'-like very dark blue background. Both build up a brightness difference between the network and the background, which lets the network appear to be glowing a bit - but just a bit, not too flashy - which is good. 'night theme' version: https://abload.de/img/logoonnightthemelikevo7jbt.png - dev screenshot: https://abload.de/img/devscreenshot-logoonnkckqe.png black background version: https://abload.de/img/logoonblackbackgroundv5sud.png- dev screenshot: https://abload.de/img/devscreenshot-logoonbvmjsc.png In general I think it's a good idea to just stick to 3 colors regarding this design: This bright blue, black/'night theme' like very dark blue, and white The text has a different color than the image. And it's not just a different alpha value making it the same color but just half way transparent instead of solid. As a result changing backgrounds becomes a hassle: The image color always stays the same - this bright blue - so you avoid backgrounds in bright blue. When you have the bright blue image with text on the black background, but the text hasn't the same color than the image, at all, then you have to make sure, that the text color additionally works out well on the background: So, with black background the text can't be black, too, but rather has to be something else, like white, for example. Same with white background. White text would vanish, so you need something else, like black text, for example. logo on black background: see the link above - https://abload.de/img/logoonblackbackgroundv5sud.png logo on white background: https://abload.de/img/logoonwhitebackgroundc6khx.png One could avoid this hassle by making the text in the same color like the image - this bright blue - but go half way down with the alpha value, so that the text is half way transparent, and so always works out well no matter what the background is. 3 nice side effects of this approach: This way text is not competing so much with image for attention. The image gets primary priority, the text second priority. Additionally this way text and image melt more together. They also do so in spacing by the 2 network like dots between the text, that's one interaction in space. The half transparency approach adds a second interaction between both, an interaction in color. And that all around forms image and text to a pretty well harmonized team. 3rdly, shaped like this the text always will integrate between the image and the background. This way in general the logo fits better into all different kinds of backgrounds. logo + half transparent text on 'night theme' like very dark blue background: https://abload.de/img/logohalftransparenttel2jn5.png logo + half transparent text on black background:
Re: [GNUnet-developers] website and logo rework
Hello, seeing the logo, this network forming the silouette of a gnu, sparked excitement in me. This is an improvement to the current logo. And it motivated me to play a little bit around with its relationship to added writing. Here's the result: https://abload.de/img/gnunetlogo-sketchesk5u5g.png My initial impulse to start this was, that I didn't like how the writing was designed in relationship to the logo: The serifs made the writing appear so antiquated. And that's exactly not what the project needs. The project needs refreshment. A timeless, modern, slick look, a look mirroring what the GNUnet is: Hot shit. Additionally it was inappropriate: Serifs have a function. They make it easier to read huge masses of text. That's why books, especially romans, are using typos with serifs. But what we have here is not a book. It's an image with maybe 1 word under it. So, no need for applying this function. Additionally, when the logo is very small, the serifs of the writing below the logo are just unnecessary shape vanishing or blurring in the eye of the beholder. Second point: A big competition for attention arises between the logo and the writing. The gnu silouette form of the logo and the horizontal form of the writing are next to each other like 2 foreign objects. They have nothing to do with each other. They do nothing with each other. They are ignoring each other. Additionally, the difference between the white and the colors of the logo including the black background made the writing so loud. Well, and with this starting point, I've made a 1st variation: Simply changing typo: Switching over to using typo's variation without serifs - GNU FreeFont, which is licensed with GPLv3orlater by itself - https://www.gnu.org/software/freefont/index.html . This aspect has it's charme, it additionally mirrors the spirit of the GNUnet. And I kind of liked the outcome. It improved some of the mentioned aspects. But not all. It was still loud. So I've made variations 2 and 3, both aiming at dimming the writing down, harmonizing image and writing more. It was kind of nice. Both prefereable to variation 1, if you ask me, but I quickly went over to something I was more excited about: Doing a variation 4, a variation based on 2 intuitive sketches I've made right away after reading this thread: Transforming the horizontal form of the writing into a T-form, which is like the space form of the gnu silouette form of the logo, and putting the writing into the logo. The charme of it was that it mirrors the image in its double meaning and additionally is efficient by saving a letter without losing completeness. It was surprising to me, that the outcome was a typical example of 'nice in the head, but not so nice in real life'. The T-space in the logo is relatively small, so you have to scale down the size of the writing. And that to a degree making the outcome too small and puzzle like for practice. This complete outcome up to this point lead me to variation 5, which is my final logo recommendation: Just use the image, and that's it. Let it speak for itself, because it can. Leave the writing under it away. Not only is that the best solution to the mentioned points, it's also something which can be pulled thanks to 2 things: Firstly, how self-explanatory the logo as such is, and secondly, the environment in which the logo is faced in general. The name of the GNUnet project consists of 2 parts: GNU and net. Both motives are perfectly blended in the logo. You have a network, and this forms the silouette of a gnu. You don't need prior knowledge to understand it. You don't need to speak a certain language to understand it. It's acultural, it's self-explanatory. And it shows what the project does: Networking. But you do need prior knowledge to get what that gnu is all about. But the same applies to the writing 'GNUnet': You can have it written down letter by letter, but if people don't know that GNU stands for the free software movement and what's that all about, then they don't understand the writing, either. So, no point of difference regarding this aspect between image and writing. In addition to that, in what context, in what environment, the logo appears most of the time? We look at a screen, seeing it in logical connection and close to something, which contains the writing 'GNU'. Maybe it's the URL in the address bar, or the hashtag of a social media message, or a keyword within a text the GNUnet website or gnu.org. Feedback regarding the website: The website has to get more to the point, and the design has to support that by how it divides spaces and shapes them with colors, images, and writings. If you want to place 5 bullet points, you better take the whole white space, and devide it into 5 parts, each designed differently custom made, individual and tasty just for that one bullet point they are supposed to introduce. Additionally, you want to keep up interest of the audience
