NOSTR group account publisher
NOSTR group account publisher
This is a small project to describe a group or organization or institution via text files.
This description can be transform to NOSTR events and published over relays. It can be used to initially set up a NOSTR account.
Details about the structure and the different kinds of Information you can provide via NOSTR can be looked up in the doc folder.
A command line tool to bootstrap a NOSTR account, for example if you want to move your stuff from a proprietary platform over to NOSTR, just as a mirror.
define the profile
A profile is described by a YAML file and define your group/profile content.
When you want to use the long form format you need to store the text in markdown in a directory and supply the program with the --articlePath Parameter.
You find examples in the directory profileExamples/ also described in the examples doc.
supported content
- profil meta data
- follow List Kind:3
- relay list kind:10002
- interrests kind:10015
- pin list kind:10001
- short Note Kind:1
- long Note Kind:30023
- Calendar Kind:31924
- Calendar Events Kind:31923
- bookmark set Kind:30003
- curation set Kind:30004
- interrest set Kind:30015
- follow set Kind:30000
- mute set Kind:30007
- starter pack Kind:39089
classDiagram
%% ---------- Hauptklassen ----------
class NostrSet {
-String dTag
-String title
-String imageUrl
-String summary
-List<Integer> kind1
-List<Integer> kind30023
-List<String> tags
-List<String> urls
-List<NostrId> profiles
-Long createdAt
}
class Media {
-String title
-String imageUrl
-String summary
-Long createdAt
-Long duration
-String contentWarning
-List<NostrResource> imeta
}
class NostrResource {
-String url
-String mimeType
-String hash
-String orgHash
-Long size
-String dim
-String magnetLink
-String torrent
-String blurhash
-String thumb
-String image
-String summary
-String alt
-List<String> fallback
-String service
}
class Profile {
-String pk
-Map<String,Object> metadata
-List<ForainId> nip39
-List<NostrId> kind3
-List<Relay> kind10002
-List<String> kind10015
-List<Note> kind1
-List<Article> kind30023
-List<Integer> kind10001
-List<NostrSet> kind30003
-List<NostrSet> kind30004
-List<NostrSet> kind30015
-List<NostrSet> kind30000
-List<NostrSet> kind30007
-List<NostrSet> kind39089
-List<Calendar> kind31924
-List<CalendarEvent> kind31923
-List<Media> kind20
}
%% ---------- Weitere Klassen (nur Referenz) ----------
class ForainId {
- String user;
- String proof;
}
class NostrId {
- String publicKey;
- String relay;
- String petname;
}
class Relay {
- String name;
- String url;
- boolean write;
}
class Note {
- String content;
- List<String> tags;
- Long createdAt;
}
class Article {
- String dTag;
- String file;
- String title;
- String imageUrl;
- String summary;
- List<String> tags;
- Long createdAt;
}
class Calendar {
- String dTag;
- String summary;
- String title;
- String imageUrl;
- List<Integer> includedCaledarEvents;
- Long createdAt;
}
class CalendarEvent {
- String dTag;
- String title;
- String summary;
- String imageUrl;
- String startTzid;
- String endTzid;
- String location;
- String geoHash;
- Long start;
- Long end;
- Long createdAt;
}
%% ---------- Beziehungen ----------
Profile "1" o-- "*" NostrSet : kind30003/04/05/...
Profile "1" o-- "*" Media : kind20
Profile "1" o-- "*" NostrId : kind3
Profile "1" o-- "*" Note : kind1
Profile "1" o-- "*" Article : kind30023
Profile "1" o-- "*" Calendar : kind31924
Profile "1" o-- "*" CalendarEvent : kind31923
Profile "1" o-- "*" ForainId : nip39
Profile "1" o-- "*" Relay : kind10002
Media "1" o-- "*" NostrResource : imeta
supported signer
- NoSigner
- NOSTR Sign device
https://nsd.lnbits.com/ - nsec
prepare the content
You define the yaml content.
see the 'profileExamples' for more details the 'group-example' is this application it self and klarmachen an old blog of mine
profile data
content
- text notes
- articles
- calendar
- following
media data - you need to store all the media on a hoster as NOSTR only serve json
- own hoster
- cloud service
- anonymous hosting via lightning
Articles should be in markdown files, in one directory, defined by their yaml values.
You can organize the content further in lists (bookmarsets) where you references notes, articles etc.
prepare the identity
NOSTR uses private public key management, you can create an account out of math.
When you want to create an institutional group, you should use a hardware device to manage the account, shared secrets are not rally a secret. The signing device allows to share the key without compromising it. In an institution people changes but institutional accounts should not.
Transferring the device can be part of the institutional transition process and should be formalized in the constitution if the organization has one.
currently supported is:
usage
first build:
./gradlew build
after you find in /nostr-account-publisher/application/build/distributions the zip.
Which contains a simple bash script to start the application.
Usage: profileCreator [-hs] [-a=<articlePath>] [-m=<signMethod>] [-o=<outPath>]
-p=<profileDescriptor> [--portHint=<portHint>]
[--privateKey=<privateKeyHex>]
Create a NOSTR profile from a YAML configuration.
-a, --articlePath=<articlePath>
the complete path to the article directory
-h, --help display this help message
-m, --method=<signMethod> The method to sign the events. Valid values: NO,
PK, HDW
Default: NO
-o, --outPath=<outPath> path to store the event json
-p, --profileYaml=<profileDescriptor>
the complete path to a yaml which describes the
profile
--portHint=<portHint> a hint to find the com port
Default: ACM
--privateKey=<privateKeyHex>
The private key as hex, valid only with the option
--method PK.
-s, --sendEvents publish the events to relays
Default: false
You can store the generated event json to file by supplying the -o parameter, use this for dry runs where you can check the data and the structure.
Single objects get a simple name, while objects in lists, like notes and articles are name by their Event Kind and the index in the list, like 23_1.json.
You can also keep them to republish to other relays or as a backup. As the events are signed, all it takes is to transmit them again.