Doesn't that break your ability to serve others that are doing IBD?
These are the winners. Please send a Lightning invoice.
These notes from more-speech that have the contents of what they're replying to quoted at the bottom are so charming: #[0]
This would be a pain to build so I don't expect anyone to do it out of pure love, but it is indeed business opportunity that may yield something.
How to benefit from Twitter for Nostr adoption?
The network effect makes it hard to replace twitter. So many people we want to follow and be followed by are on twitter. So, how can we make nostr more attractive UNTIL people move over?
A twitter "mirror" could listen to tweets from a list of accounts and create shadow identities on nostr which it uses to cross-post all tweets. This way, people could move to nostr but still follow ppl on twitter - without logging in to twitter. And without the annoying ads.
But how could we authenticate these shadow identites without the initiative or even consent of the original twitter account?
Enter trusted execution environments (TEE):
We could execute the listener inside a TEE and let it create shadow nostr accounts with a name like "POTUS [on twitter]". The keys to these accounts would be managed by the TEE and are not accessible to the operator of the service.
Then, we could use NIP-52 badges to indicate verified TEE-managed accounts (remote attestation is possible)
It should be fairly straightforward to build this including a complete audit trail with the Integritee SDK:
https://docs.integritee.network/4-development/4.4-sdk/4.4.2-trusted-off-chain-worker
caveats:
* not sure what legal implications apply if we cross-post without consent
* we probably should offer opt-out to be fair to twitterers who do not want to be cross-posted to nostr
* it may make sense to use a specialized set of relays for this, so people can choose to see such cross-posts or not
I don't think we need TEEs. It would be ok to trust some kind person who went into the trouble to make these things.
I had a bounty for a Mastodon bridge here: https://gist.github.com/fiatjaf/ea7d21e81359e1eb8abcb8805306adaa
A guy was working on it, but I don't know if he gave up or what.
Try going to https://github.com/mikedilger/gossip/actions, clicking on the latest successful build and looking for the "Artifacts" section at the bottom. There are Windows builds there. Would be nice if someone with a Windows computer tried them because I don't know if they work.
Because the Damus first implementation used some pieces of Swift bech32 code that happened to be bech32-not-m and then it wasn't worth changing the standard later.
Answering https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416566716:
I just chose YAML because it is common practice out there for blog software and static site generators out there to use Markdown with a YAML front-matter for metadata, mostly because it is very readable as plaintext I believe and easy to write by hand.
Considering that I think it makes no sense to use TOML, since it would be introducing yet a new dependency and nothing would be gained. I'm considering now that it makes no sense to have this be in YAML since no one will be writing these by hand ever anyway, so just using JSON will probably be a better solution.
And yet, now that you asked why not use that "subject" tag that already exists, I see that it is probably better to just use normal tags for everything and get rid of the front-matter completely. This simplifies parsing as you don't have to split the article string, then run it through a parser and whatnot.
So we should just use tags for everything, a tag `["title", "Lorem Ipsum"]`, other tags for other things that may appear, like `["summary", "..."]`. What else?
Why not use the "subject" tag? That tag only has meaning on `kind:1` events and we gain nothing by reusing it here. It would just confuse things.
Answering https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416566716:
I just chose YAML because it is common practice out there for blog software and static site generators out there to use Markdown with a YAML front-matter for metadata, mostly because it is very readable as plaintext I believe and easy to write by hand.
Considering that I think it makes no sense to use TOML, since it would be introducing yet a new dependency and nothing would be gained. I'm considering now that it makes no sense to have this be in YAML since no one will be writing these by hand ever anyway, so just using JSON will probably be a better solution.
And yet, now that you asked why not use that "subject" tag that already exists, I see that it is probably better to just use normal tags for everything and get rid of the front-matter completely. This simplifies parsing as you don't have to split the article string, then run it through a parser and whatnot.
So we should just use tags for everything, a tag `["title", "Lorem Ipsum"]`, other tags for other things that may appear, like `["summary", "..."]`. What else?
Answering #[0] at https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416557909:
> i find all this nref things a bit confusing and anti pattern for nostr. I think the document should be able to referenced by note1d and it's hex protocol id, and we should be able to see the edits, so a list of versions
We already do not reference public keys by their metadata event id, when that would have been sensible, right? I think it is the same with parameterized replaceable events.
I agree it feels weird to refer to something that is not an event, and also that it would be ideal to have a history of all edits a document has ever had, and specially to have a reference to the point in the entity history on which you are commenting (i.e. I make a comment today about a thing, tomorrow it changes to its opposite, my comment has its meaning inverted, not cool) -- but for this to work we would have to rely on relays keeping a ton of possibly very large events and we don't want that.
I think the solution is for the comment to tag both the "ref" (i.e. combination of pubkey, kind and "d" tag) and the event id -- and while doing that, if possible, also push that exact event (i.e. the "ref" at that point in time) to a special archive relay that will not delete that event or overwrite it -- so others can then later fetch the event at the specific date.
I think this "ref" name is bad and it would be better to call it "entity" -- also in my PR above I am referring to these things using only "pubkey" and "identifier" ("d" tag), but I think they should also contain the "kind".
If we decide to all any "parameterized replaceable event" an "entity" instead, that will make everything simpler. And links could be beautiful with the "nent1..." prefix, tags become `["n", "
Answering #[0] at https://github.com/nostr-protocol/nips/pull/220#issuecomment-1416557909:
> i find all this nref things a bit confusing and anti pattern for nostr. I think the document should be able to referenced by note1d and it's hex protocol id, and we should be able to see the edits, so a list of versions
We already do not reference public keys by their metadata event id, when that would have been sensible, right? I think it is the same with parameterized replaceable events.
I agree it feels weird to refer to something that is not an event, and also that it would be ideal to have a history of all edits a document has ever had, and specially to have a reference to the point in the entity history on which you are commenting (i.e. I make a comment today about a thing, tomorrow it changes to its opposite, my comment has its meaning inverted, not cool) -- but for this to work we would have to rely on relays keeping a ton of possibly very large events and we don't want that.
I think the solution is for the comment to tag both the "ref" (i.e. combination of pubkey, kind and "d" tag) and the event id -- and while doing that, if possible, also push that exact event (i.e. the "ref" at that point in time) to a special archive relay that will not delete that event or overwrite it -- so others can then later fetch the event at the specific date.
Moving the discussion about this PR https://github.com/nostr-protocol/nips/pull/220 to here.
Other relay ideas (not very good, just to sparkle your imagination):
- a relay only for people with top-level domain names (no "@" at the NIP-05)
- a relay that only stores the most recent post of people
- a relay that only stores posts that have received at least 10 replies from other people (big threads)
- a relay that only serves posts to people "bitcoin" on their profile metadata
The most interesting crazy relay idea to comment on this post will earn a marvelous prize of 10000 sats.
I don't think I would use this: #[0], but if it worked it would create a certain aura of exclusivity for content posted in this relay. Better yet if you restrict reads somehow, make them harder to get or something like that.
No, that is too complex and unnecessary.
I believe https://coracle.social and https://astral.ninja. Damus has said they will implement.
I don't always test my code, but when I do I do it in production.
