curl_easy_cleanup is called twice (lines 126 and 128) in case of an error. Similarly in other code blocks.And you're leaking memory: https://curl.se/libcurl/c/curl_slist_append.html You gotta have to call
curl_slist_free_all. Maybe use a cURL C++ wrapper library or write your own wrapper around the C library to make your life a bit easier.Regarding escaping the JSON input for your HTTP requests, have a look there: https://rapidjson.org/md_doc_stream.html#StringBuffer This is probably the easiest.
Yeah, I know, small baby steps. :-)
If it still fails I'll make a twtxt account and look into it more.
#running
#running
#running
#running
I also agree that buckket's twtzt dlient makes a terrible Yarn client -- I would even go so far as to say it's not very well maintained either as it has been broken for some time π’
Yes we can raise a PR against the original reference client -- But I'm not convinced it'll get accepted π’
I also agree that buckket's twtzt dlient makes a terrible Yarn client -- I would even go so far as to say it's not very well maintained either as it has been broken for some time π’
Yes we can raise a PR against the original reference client -- But I'm not convinced it'll get accepted π’
I also agree that buckket's twtzt dlient makes a terrible Yarn client -- I would even go so far as to say it's not very well maintained either as it has been broken for some time π’
Yes we can raise a PR against the original reference client -- But I'm not convinced it'll get accepted π’
What if instead of signing each twt individually we generated a merkle tree using the twt hashes? Then a signature of the root hash. This would ensure the full stream of twts are intact with a minimal overhead. With the added bonus of helping clients identify missing twts when syncing/gossiping.
Have two endpoints. One as the webfinger to link profile details and avatar like you posted. And the signature for the merkleroot twt. And the other a pageable stream of twts. Or individual twts/merkle branch to incrementally access twt feeds.
What if instead of signing each twt individually we generated a merkle tree using the twt hashes? Then a signature of the root hash. This would ensure the full stream of twts are intact with a minimal overhead. With the added bonus of helping clients identify missing twts when syncing/gossiping.
Have two endpoints. One as the webfinger to link profile details and avatar like you posted. And the signature for the merkleroot twt. And the other a pageable stream of twts. Or individual twts/merkle branch to incrementally access twt feeds.
--? I sometimes try to separate different paragraphs or points with a -- instead of a new line / paragraph break. I don't mind either way, but will amend the PR later when I get back from the tournament, unless you'd like to make the suggested change and I'll just accept it? π
--? I sometimes try to separate different paragraphs or points with a -- instead of a new line / paragraph break. I don't mind either way, but will amend the PR later when I get back from the tournament, unless you'd like to make the suggested change and I'll just accept it? π
--? I sometimes try to separate different paragraphs or points with a -- instead of a new line / paragraph break. I don't mind either way, but will amend the PR later when I get back from the tournament, unless you'd like to make the suggested change and I'll just accept it? π
Also whilst I understand the appeal of
curl url | less to read a feed, I find this a terrible user experience in the first place, yes it should be possible to use UNIX text manipulation tools for feeds, which is why using Twtxt as the "spec" and "transport" of the content is so ideal. -- Should you read feeds this way primarily? Probably not.
Also whilst I understand the appeal of
curl url | less to read a feed, I find this a terrible user experience in the first place, yes it should be possible to use UNIX text manipulation tools for feeds, which is why using Twtxt as the "spec" and "transport" of the content is so ideal. -- Should you read feeds this way primarily? Probably not.
Also whilst I understand the appeal of
curl url | less to read a feed, I find this a terrible user experience in the first place, yes it should be possible to use UNIX text manipulation tools for feeds, which is why using Twtxt as the "spec" and "transport" of the content is so ideal. -- Should you read feeds this way primarily? Probably not.
twtxt client, including support for multi-lines (\u2028), I suppose anyone (even I) could put up a PR that addresses that, it's a trivial 1-line patch.As for your very positively written position and point, absolutely 100% π The fact that some folks write cryptic posts to their Twtxt feed (e.g: the feed that posts geospatial coordinates updates and a status of some reading off a device), or some other formats (rare, but do exit), plain text, Markdown or HTML are all attributes of what the author chooses to write. Probably the only form that would be quite hard to cope with _manually_ would be XML/HTML π€£
twtxt client, including support for multi-lines (\\u2028), I suppose anyone (even I) could put up a PR that addresses that, it's a trivial 1-line patch.As for your very positively written position and point, absolutely 100% π The fact that some folks write cryptic posts to their Twtxt feed (e.g: the feed that posts geospatial coordinates updates and a status of some reading off a device), or some other formats (rare, but do exit), plain text, Markdown or HTML are all attributes of what the author chooses to write. Probably the only form that would be quite hard to cope with _manually_ would be XML/HTML π€£
twtxt client, including support for multi-lines (\u2028), I suppose anyone (even I) could put up a PR that addresses that, it's a trivial 1-line patch.As for your very positively written position and point, absolutely 100% π The fact that some folks write cryptic posts to their Twtxt feed (e.g: the feed that posts geospatial coordinates updates and a status of some reading off a device), or some other formats (rare, but do exit), plain text, Markdown or HTML are all attributes of what the author chooses to write. Probably the only form that would be quite hard to cope with _manually_ would be XML/HTML π€£
twtxt client, including support for multi-lines (\u2028), I suppose anyone (even I) could put up a PR that addresses that, it's a trivial 1-line patch.As for your very positively written position and point, absolutely 100% π The fact that some folks write cryptic posts to their Twtxt feed (e.g: the feed that posts geospatial coordinates updates and a status of some reading off a device), or some other formats (rare, but do exit), plain text, Markdown or HTML are all attributes of what the author chooses to write. Probably the only form that would be quite hard to cope with _manually_ would be XML/HTML π€£
> Recently (research and documentation begun in 2007) I have had sufficient experience with a variety of different types of trolls on the internet (in communities, email lists, wikis, and news stories) that it seemed useful to document, categorize, classify, and provide methods for dealing with each type, towards the goal of identifying and defeating trolls as quickly as possible in the interest of creating and maintaining PositiveCommunities.
May be something good to learn from here π€π
> Recently (research and documentation begun in 2007) I have had sufficient experience with a variety of different types of trolls on the internet (in communities, email lists, wikis, and news stories) that it seemed useful to document, categorize, classify, and provide methods for dealing with each type, towards the goal of identifying and defeating trolls as quickly as possible in the interest of creating and maintaining PositiveCommunities.
May be something good to learn from here π€π
> Recently (research and documentation begun in 2007) I have had sufficient experience with a variety of different types of trolls on the internet (in communities, email lists, wikis, and news stories) that it seemed useful to document, categorize, classify, and provide methods for dealing with each type, towards the goal of identifying and defeating trolls as quickly as possible in the interest of creating and maintaining PositiveCommunities.
May be something good to learn from here π€π
yarn.txt feed and a stripped-down and limited twtxt.txt feed. But I am 98% convinced this wouldn't solve any of the perceived problems, actually I'm 100% certain. Mostly because there are no offered solutions, no actionable feedback, no contributions, just complains and arguments.
yarn.txt feed and a stripped-down and limited twtxt.txt feed. But I am 98% convinced this wouldn't solve any of the perceived problems, actually I'm 100% certain. Mostly because there are no offered solutions, no actionable feedback, no contributions, just complains and arguments.
yarn.txt feed and a stripped-down and limited twtxt.txt feed. But I am 98% convinced this wouldn't solve any of the perceived problems, actually I'm 100% certain. Mostly because there are no offered solutions, no actionable feedback, no contributions, just complains and arguments.
yarnd such that it:1. produced a
twtxt.txt feed that stripped \u2028 so all posts are single-line.2. converted Markdown to "plain text"
3. limited posts to 140 characters
Would this make few that scream and shout the loudest happier that Yarn is more _properly_ using Twtxt? π€ Would Yarn _then_ be considered to be using Twtxt as-it-is/was intended? π€
Of course this would have the side effect of:
- Your longer posts would now be truncated and meaningless.
- Posting links to images would no longer work.
- Threading would no non-existent.
And so we're back to square one, where Twtxt as-it-was-is intended is a spec that whilst on its own useful for a very limited number of use-cases it lacks certain features that make microBlogging and interacting with others viable.
yarnd such that it:1. produced a
twtxt.txt feed that stripped \u2028 so all posts are single-line.2. converted Markdown to "plain text"
3. limited posts to 140 characters
Would this make few that scream and shout the loudest happier that Yarn is more _properly_ using Twtxt? π€ Would Yarn _then_ be considered to be using Twtxt as-it-is/was intended? π€
Of course this would have the side effect of:
- Your longer posts would now be truncated and meaningless.
- Posting links to images would no longer work.
- Threading would no non-existent.
And so we're back to square one, where Twtxt as-it-was-is intended is a spec that whilst on its own useful for a very limited number of use-cases it lacks certain features that make microBlogging and interacting with others viable.
yarnd such that it:1. produced a
twtxt.txt feed that stripped \\u2028 so all posts are single-line.2. converted Markdown to "plain text"
3. limited posts to 140 characters
Would this make few that scream and shout the loudest happier that Yarn is more _properly_ using Twtxt? π€ Would Yarn _then_ be considered to be using Twtxt as-it-is/was intended? π€
Of course this would have the side effect of:
- Your longer posts would now be truncated and meaningless.
- Posting links to images would no longer work.
- Threading would no non-existent.
And so we're back to square one, where Twtxt as-it-was-is intended is a spec that whilst on its own useful for a very limited number of use-cases it lacks certain features that make microBlogging and interacting with others viable.
yarnd such that it:1. produced a
twtxt.txt feed that stripped \u2028 so all posts are single-line.2. converted Markdown to "plain text"
3. limited posts to 140 characters
Would this make few that scream and shout the loudest happier that Yarn is more _properly_ using Twtxt? π€ Would Yarn _then_ be considered to be using Twtxt as-it-is/was intended? π€
Of course this would have the side effect of:
- Your longer posts would now be truncated and meaningless.
- Posting links to images would no longer work.
- Threading would no non-existent.
And so we're back to square one, where Twtxt as-it-was-is intended is a spec that whilst on its own useful for a very limited number of use-cases it lacks certain features that make microBlogging and interacting with others viable.
where none of them work with one another and there's no effective bridging, data or identity portability.
where none of them work with one another and there's no effective bridging, data or identity portability.
where none of them work with one another and there's no effective bridging, data or identity portability.
=> https://files.mills.io/download/Twtxt%20IRC%20Logs%202023-04-14.md=
=> https://files.mills.io/download/Twtxt%20IRC%20Logs%202023-04-14.md=
=> https://files.mills.io/download/Twtxt%20IRC%20Logs%202023-04-14.md=