Piero Bosio Social Web Site Personale

so if you rip out the markdown parser and treat markdown as a set of conventions instead of a codified language, then which conventions actually make sense to keep? if you're just concerned with visual appearance, i guess you can do whatever you want as long as it isn't parsed. but then what do you *actually* need to parse? i'd say the main/only thing i care for is links -- i want to be able to make consistent references between notes etc. markdown links are ambiguous with paraphrasing quotes...

thanks giving? in this economy?

@oblomov that's not how it's used nowadays though. maybe in an alternate timeline markdown would have evolved more in the direction of NFO files or the ascii art headers you would see at the top of gamefaqs walkthroughs, instead of people treating it like you can write blog posts in it

i went into more detail in a subthread with someone else on followers-only scope but basically i would in almost every case prefer either plain text or HTML

markdown is exactly the kind of minimalism i hate, it is more restrictive than simplifying. actually i am fine with markdown so long as it is not parsed by a markdown parser -- it makes a lot more sense as a *microsyntax* and not an actual markup language. you can encode some limited semantics with it (things like emphasis), but you cannot encode any significant structure except what might be inferred implicitly by e.g. heading levels. i would not want to author everything in markdown.

@mcc because poseven poate ponine

mastodon api is to fedi as amazon s3 api is to object storage

proprietary and nonstandard, but people adopt it for compatibility with an existing ecosystem of software. if you didn't know any better you might think it *was* a standard, based on how many different providers implemented it. unofficial implementations have to keep track of differences in their implementations, ideally describing which operations and features are supported or unsupported at a granular level.

blogs. forums. wikis. personal websites. long ago, the four nations lived in harmony. then everything changed when the social media attacked

@oblomov i meant more like a standard that works across multiple programs

concept: VSTs but for image editors

concept: a genie will grant you three wishes, but after that you become the genie. this is how all genie lamps work

EDIT: assume for the sake of interesting worldbuilding that genies cannot communicate this information to anyone else, so people would not find out unless they met a former genie who chose to divulge that information for whatever reason

french cream cheese alignment chart
- kiri: good
- the laughing cow: neutral
- président: evil

@julian > strict inheritance of the root object's context

only if the "root" (of the reply tree, i assume) has the same context you want to participate in. there are plenty of situations where you *don't* necessarily want to do this. replies can cross contextual boundaries, so you need to account for this.

@julian @jesseplusplus so generally creating your own context is something you'd want to do if you e.g. "fork" the thread, but you can also be like what lemmy is proposing and just always create your own local context, as long as you give consumers a way to link/merge equivalent contexts together (via something like as:alsoKnownAs or owl:sameAs, or otherwise something like rel=canonical)

@julian @jesseplusplus i don't think that's the right way to look at it. the reply tree and the context are separate things. you can *try* to find the root of the reply tree, but even if you do, there is no hard requirement to copy that context vs any other context. you get to choose which conversation you want to be a part of, including choosing *not* to be part of a conversation. also, any id may be equivalent to other ids. what you want is to arrive at the same information.

@silverpill @julian @forum-wg @dmitri

POST to inbox instead of sharedInbox implies bto/bcc if the inbox owner is not present in to/cc.

what this has to do with threaded discussions i'm not sure, but for delivery and signing, SMTP has the same issue which they solved by making delivery *not* depend on the payload headers but instead on the SMTP envelope (there is a RCTP TO instruction in the SMTP connection, specifying inboxes that should receive the payload)

you know what they say, luigi... all posters post posts

@julian @helge also if you used HTTP as a messaging protocol then yes you very well might persist HTTP messages just like you would persist any other RFC(2)822-style internet message (SMTP, etc). it's entirely incidental that most HTTP messages are ephemeral. logging is a separate concern.

@julian @helge no, activitystreams is a data format for *describing streams of activities*, and activitypub is a protocol for *publishing streams of activities*. if you're not working directly with activities then you're going to have a bad time because you are actively fighting the specs and the inherent design of those specs, which are built on activities as the primary unit of content.

@helge @julian most "fedi" instances would be better served by a state synchronization protocol, but activitypub is Not That. you can't replay an outbox as a chronological event log. activitypub is better fit to be a notification protocol with built-in persistence (as opposed to linked data notifications which are just direct HTTP POST requests and do not automatically persist).