settings view and write new message didnt show. reason was typescript
expected an instance of an HTMLElement but this didnt allow for
SVG elements inside the write button. Another reason was that the
condition expected a parent with data-id which isn't the case for
settings button nor write-new-message.
starting to move global application user config to settings.ts.
plan is to only share user settings via the config object, with
this all settings related ui can be moved out of main.js into its
own module.
use attributes of html element type.
so that the following example is correctly typed:
elem('input', {
className: 'foo',
hidden: false,
onclick: () => alert('hi'),
tabIndex: 1,
valueAsNumber: 1,
});
but this fails as foo is no valid attribute on div element:
elem('div', {foo: 'bar'});
typed elem so that it returns the exact type of the HTMLElement,
and that name must be a key of HTMLElementTagNameMap.
example:
elem('form'); // returns HTMLFormElement
elem('abc'); // not assignable to parameter of type 'keyof HTMLElementTagNameMap'
convert pubkey to npub and event id to note and store for
later. use npub and note for uri's so that we dont need to
guess what the view of a specific uri has to render.
this is only the first step that changes uri's, next step is
for the view to react to npub or note and render the
correct view accordingly.
move and typed relay related code to relays.ts
upgrade nostr-tools to latest greatest, major version with
breaking changes:
- relayPool is gone in favor of SimplePool, but this commit just
used relayInit directly as relays should become configurable at
some point
proof of concept to use generic view containers instead of specifc
functions to show and hide particular views.
a view has an identifier (path) which is used to subscribe to
relevant data. changing a view updates the history so that browser
back displays the last view. each view container has its own
scrollbar so that the scrolling position should be preserved when
changing back and forth between different views.
this change also removes CSS tabs in favor of view or overlays
such settings or write a new text note.
profile and notes deeplink use now native HTML anchors to improve
accessibility (copy/paste, open-in-new-tab, search engines).
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
there is currently lots of chinese spam, probably since damus was
accepted in appstore.
temporary disabled damus, snort.social and nostr.info relays, and
added some less known german and swiss relays.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
relay.snort.social seems to be a popular relay, adding a new one
to the hardcoded list of relays, this should be configurable in
the future.
related damus relay is often not responding or slow, but keeping
it for now.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
instead of just adding 1 line for all replies to point to the
original note, using smaller profile pic for replies of replies
help to understand the context of the replies.
this is done without increasing indentation as heavy nesting can
mess up the layout so only indentation is visible and the space
for the actual content gets to small.
if needed users can inspect replies and navigate to the deeplink
to see how the next 3 levels are nested.
replies were not sorted correctly, reason for this was that an
array of dom elements was sorted, but instead it should sort the
notes.
regression introduced in:
- 2e40a273c4
a fast relay might return a newly published note within the same
second, but nostrweb only shows notes that are older than now.
was introduced in 4a68940681
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
before this change every new incoming text note called a render,
that filters, sorts and iterates all known text notes and creates
missing dom elements and appends into the right place.
this change throttles and debounces (both!) the render function,
that less checks have to be performed, especially on page load
when potentially 100s of events arrive within a short time.
it is important to throttle and debounce, else either the last call
is missed or no render is called while events are being received.
this change surfaced an error in recommend server that depended on
all known text notes already being rendered and inside the dom.
this function should probably be handled by render feed itself.
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
some replies rendered twice in different positions, seems to be
related to deprecated positional event tags and a regression
introduced in a596121821
on receiving events it analizes the event tags and stores the id
of the replied event so the client can easily search for replies
later. marked tags are prefered with a fallback to positional tags
as described in nip-10.
mentions are ignored at the moment.
example event that had some replies rendered twice:
22e4ea80161ac591059da611d3ab63c583cb1d47a706826db2fc6955ac0a70b5
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
some words were incorrectly detected as links.
changed:
- split words by any whitespace character, not just char 32
- match words _beginning_ with http, https or www.
example of broken link user white space character code 160, see:
feb290999a2746bf0914ede8a811b52eccd423f9f5373232e4f5947131fb47aa
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
before it was only testing if the nonce commitment is high enough
but didn't verify leading zero bits.
with this change rendering checks now the leading zero bits count
of the event id.
OFF0